|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Ты почти все верно понял. Но нужна немного иная таблица. Для каждого из 59 единиц оборудования нужно 24 строки. Каждая строка - час завтрашних суток. Если в ремонте, то ставлю маркер. Вот окончание запроса, которое я отрезал Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Далее эти 59х24 строки поступают на вход Системы, которая уже их обрабатывает нужным образом. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 14:44 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Begimot441Вот окончание запроса, которое я отрезал Вот поэтому-то и надо с данным вопросом идти не на форум, а к старшим товарищам, которые знают конкретную базу конкретной системы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 15:08 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, А что эти товарищи могут сказать? Чем помочь? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 15:10 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Расскажут как и из каких таблиц правильно доставать нужную информацию. Хотя бы для того чтобы не хардкодить в запросе список оборудования и не доставать операцию из описания. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 15:23 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Ну что, начнем оптимизацию :) Я целиком ЗА обращение к старшим товарищам, ибо как именно задумана структура данных иначе маловероятно получить, тем более что структура хоть и не самая плохая, но теми же FK - не страдает. Судя по показанным тут DDL Но чисто из любопытства попробую показать процесс оптимизации для начинающих :) Берем начало и смотрим статистику. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69.
Получить на 458 записей 210 тысяч чтений - это круто. Но это явно херня. Конструкция and (Id IN (SELECT Id FROM freshIdWithTarget)) явно не для этих случаев. Однако, у нас же псевдотаблица, чего мы с ней по человечески, джойном, не работаем?? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73.
И вместо 210 тысяч чтений мы получаем 458 штук натуралом + 161 штуку через индекс. Уже лучше чем было. Если что - исходный запрос с данными, я вообще не дождался окончания выполнения, срубил его :) Если у тебя он выполняется за 30 секунд - у вас очень хороший сервер. Или ты чего-то не договариваешь. Предоставляешь не ту инфу с которой работаешь сам. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 16:46 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Мдя. Последний join Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
fullCombin (1416 записей, ) correctHours (4 записей, 1832+696 чтений) дает 1416 записей при (ni=2 360 760 + i=980 280) чтений. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 17:23 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, спасибо! Я применил первую рекомендации + убрал кое-что лишлее и полный запрос вместо минуты стал работать 20 сек. По поводу "недоговариваешь". Я могу что-то путать по неопытности, но не вру. См. картинку. Старшие товарищи....Хорошо звучит, но плохо работает. Тот, кто работал в иностранной компании меня поймет. Есть Система. Она разработана для многих проектов. Я веду несколько длоков нашего русского проекта. По моим блоков есть ряд запросов, которые я должен выполнить на базе Системы. Если я обращаюсь к старшим товарищам за океан с просьбой что-то доделать или пояснить, то они мне вежливо объясняют, что мы тут русские идиоты, ничего не понимаем, что сами хотим, что у нас шаловливые ручки и т.п. А задачу, которая конкретно поставлена в проекте, надо делать мне и я за нее отвечаю премией. Поэтому сомое приемлимое в моем случае - найти способ использовать те системные ресурсы, что есть, для достижения того, что надо.... Вот так и живу. Спасибо, что помогаешь мне! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:18 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Begimot441они мне вежливо объясняют, что мы тут русские идиоты, ничего не понимаем, что сами хотим, что у нас шаловливые ручки и т.п. Это явно свидетельствует, что ты не сумел правильно задать вопрос, вляпался в ситуацию XYZ и действительно не понимаешь что и зачем от тебя требуют. Обращения должны быть конкретны и недвусмысленны. Например, предоставить документ с описанием всех таблиц в БД и информации хранящейся в их полях. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:31 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Замена fullCombin на физическую таблицу ничего не дает. Begimot441 Вот окончание запроса, которое я отрезал Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Далее эти 59х24 строки поступают на вход Системы, которая уже их обрабатывает нужным образом. Это "окончание запроса" должно быть не в конце запроса. Ибо результат "correctHours" - всего 4 записи в которых есть информация, а после соединения с "fullCombin" образуется 1416 записей, из которых только те 4 имеют смысловую нагрузку и те поля которые используются в том окончании запроса. Огромный вопрос - зачем присоединять типа справочник, причем непонятно чего, что бы чего-то там дальше что-то обрабатывало? Зачем эта информация без смысла, в дальнейшей обработке? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:07 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
В результате Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
получается некий набор данных, не имеющий первичного ключа. А потом мы его джойним с Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
по полю, не являщимся первичным ключом. Физический смысл этого действа? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:14 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Begimot441 Для каждого из 59 единиц оборудования нужно 24 строки. В какой таблице список этих единиц? Какой первичный ключ? Каким образом таблица RECORDS ссылается на единицу оборудования? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:20 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Begimot441Вот окончание запроса, которое я отрезал Вот поэтому-то и надо с данным вопросом идти не на форум, а к старшим товарищам, которые знают конкретную базу конкретной системы. Похоже что все старшие товарищи сидят где-то в америках/индиях/итп, а мы общаемся с самым старшим из тех что есть тут. При этом этот старший может быть вообще, менеджером по продажам :) Знаком с подобными ситуациями :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:35 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Begimot441 Далее эти 59х24 строки поступают на вход Системы, которая уже их обрабатывает нужным образом. Что такое Система, есть ли там документированное API? Или это так же творчество каких-то местных товарищей? Ну или не местных. Короче, не авторов системы. Типа мы тут вяжем веники, но попалась какая-то оглобля которая весь веник ломает. Как эту оглоблю правильно привязать? IMHO проблема кроется несколько выше чем вы пытаетесь ее решить. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:38 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Что такое задачи (task)? Зачем рассматриваем все таски, почему не отсеиваем закрытые? Почему думаем что максимальный RECORDS.ID имеет отнощение к ремонту? Почему думаем что max(RECODS.Ts2) имеет отношение к max(RECODS.Id)? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:45 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Что такое RECORDS.status? Почему он не коррелирует с RECORDS.Description? DATEADD(hour, 5, - это смещение на местный часовой пояс, система пишет дату-время в GMT? Абстрактно. В таких запросах нехорошо писать Код: plsql 1. 2.
лучше писать все поля полностью, это дает возможность нормально проследить/(прогрепать) откуда оно взялось. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:50 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
У меня тут получилось радикально ускорить последний джойн Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
но тут я натолкнулся на ограничение Firebird - максимум 255 конекстов в одном запросе. т.е. делать псевдотаблицы через UNION ALL чревато еще и этим. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 20:31 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Скрипт реализации таблицы fullCombin в виде физической таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 20:43 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Оптимизированный запрос, с использованием физической fullCombin Использовать псевдотаблицы в данном случае не получится, наткнемся на ошибку
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292.
План, время выполнения. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
Фишка ускорения - мы не делаем полного джойна. Сначала тянем записи с данными + джойн справочника. Это быстро. Потом через UNION ALL тянем весь справочник, без данных. Зная что записей данными у нас только по одной, делаем group by по полям справочника (= первичный ключ справочника, если бы он был) а по полям с данными можно делать хоть что, к примеру max() - там покажет либо NULL где были только записи из справочника, либо некие данные если по этим полям ПК справочника были записи не только справочника. Выполняется за 46ms. Сравнить выдаваемые результаты мне не с чем - исходный запрос у меня уходит в бесконечность. В любом случае - это неправильный путь решения задачи. Нужно делать по другому. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 20:56 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Скрипты таблиц + данные для тестирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 21:09 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, авторОгромный вопрос - зачем присоединять типа справочник, причем непонятно чего, что бы чего-то там дальше что-то обрабатывало? Справичник оборудования (59 строк) и часов (24 строки) несут в себе коды. По этим кодам БД-приемник (куда я все это в итоге направляю) помещает данные по нужным тегам. (Это специализированная БД, менять я там ничего не могу) авторЗачем эта информация без смысла, в дальнейшей обработке? Если вопрос в том, зачем столько информации, в которой нули, то они нужны. Они ставят нули там, где вчера были единички. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 04:49 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, авторФизический смысл этого действа? Смысл в том, что сначала я подготовил полную таблицу, где на на каждое из 59 единиц оборудование заводится 24 часа (59х24). Это как бы вся развертка. Затем я присоединяю к ней полезную информацию, чтобы указать в какой час завтрашних будет ремонт, а в какой нет. Для этого я рассматриваю варианты: 1. Завтра ремонт целые сутки, тогда все 24 часа ставлю маркер 1; 2. Завтра, например в 9 утра, начало ремонта. Тогда я помечаю маркером все часы начиная с 9 до конца суток; 3. Завтра, например в 13 дня, завершение ремонта. Тогда я, соответственно с первого часа да 13 ставлю маркер; 4. Завтра, например, короткий ремонт с 10 до 18. Тогда маркеры с 10 до 18, остальные нули. Плюс еще особенность, что сутки начинаются с 2 часов. Завод в Сибири, а отчитывается по времени Москвы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 04:59 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, авторПохоже что все старшие товарищи сидят где-то в америках/индиях/итп, а мы общаемся с самым старшим из тех что есть тут. При этом этот старший может быть вообще, менеджером по продажам :) Знаком с подобными ситуациями :) Я не настолько умен, чтобы быть менеджером по продажам.)) Я уже сказал, кто я. Я технический руководитель нескольких блоков. Вы сразу поняли, что я не настоящий программист и не лютый спец по SQL. Это верно. Я специалист по автоматизации технологического оборудования, а подобные вещи, как SQL-запросы, вынужден применять. Прекрасно понимаю, что мне не хватает знаний в этом направлении. Поэтому у вас и учусь. И вы мне в этом здорово помогаете, за что спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 05:07 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, авторВ какой таблице список этих единиц? Оборудование перечислено в теблице FOLDERS . Но там оно не все. Если по оборудованию еще не было отключений, оно туда еще и не попало. С другой стороны, полный перечень оборудования в моей псевдотаблице baseObjeclList . В ней я указываю codeAdd - это прибавка для формирования кода оборудования для целевой записи. авторКакой первичный ключ? Первичный ключ в таблице FOLDERS - видимо UID . Тут я плохо разбираюсь, а тебе я направлял DDL. Проверь сам, пож-та авторКаким образом таблица RECORDS ссылается на единицу оборудования? Посредством поля FOLDERID ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 07:36 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
Есть еще какие-то конкретные вопросы? Заставлять тебя разбираться в твоей системе, кучей наводящих вопросов, уже что-то надоело. Просто читать лекции - как бы не мне оно надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 09:17 |
|
Прошу совет по оптимизации запроса
|
|||
---|---|---|---|
#18+
fraks, авторЧто такое задачи (task)? Зачем рассматриваем все таски, почему не отсеиваем закрытые? TaskId - это идентификатор группы записей. Когда событие корректируется, то прибавляется новая запись с новыми данными, но с тем же TaskId. Я уже сам понял, что я не отсеивал устаревшие данные. А устаревшие данные - это те, у которых время окончания события раньше, чем текущее время запроса. Это можно добавить в начало. Я у себя добавил, время запроса уменьшилось с 20 сек до 13 сек. авторПочему думаем что максимальный RECORDS.ID имеет отнощение к ремонту? Почему думаем что max(RECODS.Ts2) имеет отношение к max(RECODS.Id)? Это у меня осталось в виде мусора, сорри. Это можно удалить. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2021, 09:19 |
|
|
start [/forum/topic.php?fid=40&msg=40121397&tid=1559857]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 242ms |
total: | 412ms |
0 / 0 |