|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Приветствую. Есть много запросов такого типа: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Если delete заменить на select *, то сути это не изменит. Так вот, запросы эти дико тормозят (выполняются более чем суток, потом я их прибиваю). По каждому полю каждой таблицы, которые участвуют в where вложенного запроса есть fk-индекс + у utable стоит unique на все поля. У полей, которые участвуют в join-е, есть pk- и fk- индексы. Примерное количество записей в таблицах: utable ~25000, в наибольшей table* ~5 млн. Все поля в запросе - integer Статистика индексов посчитана. В какую сторону копать? Если надо, выложу реальные ddl и запросы. PS: Система работает с разными СУБД. На тех же данных (но без fk-индексов) последний постгрес отрабатывает менее чем за 10 секунд на не разогретой базе. Надо что-то придумать, чтобы чтобы FB не сильно от него отставал. PPS: FB 2.5.8.27089 x64, 10я винда PPPS: если переписать запрос на right join с where is null, то ситуация не улучшается. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:01 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, я так понимаю запрос совсем не реальный, ибо условий соединения в join нет. NOT EXISTS плохо оптимизируется, HASH OUTER JOIN у нас пока нет ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:10 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, 5 млн - это не сутки, в любом случае. иногда делаю Код: sql 1. 2. 3. 4. 5. 6.
PS можно через курсор WHERE OF ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:28 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
pastor иногда делаю ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:38 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
можно пример хоть маленько приближенный к реальным метаданным? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:47 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
WildSery pastor иногда делаю mea culpa, mea maxima culpa конечно же LEFT ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 12:30 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Ivan_Pisarevsky, Поубирал из ddl-ля поля, которые не участвуют в запросе, но всё равно много получается. Вот такое удаление выполняется почти сутки (скоро буду прибивать): Код: sql 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.
Количество записей history - 5 млн, fast_history - 25000, history_row - 1.5 млн, history_table - 400 тыс, files - 60тыс. Остальные - несколько десятков ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 14:10 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, план запроса какой? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 14:17 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
kdv, PLAN JOIN (JOIN (H INDEX (FK_HISTORY_IDCOMP, FK_HISTORY_IDUSER), JOIN (T INDEX (FK_HISTORYTABLE_IDNAME), F INDEX (PK_FILES_ID))), R INDEX (PK_HISTORYROW_IDROW)) PLAN (FAST_HISTORY NATURAL) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:05 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen kdv, PLAN JOIN (JOIN (H INDEX (FK_HISTORY_IDCOMP, FK_HISTORY_IDUSER), JOIN (T INDEX (FK_HISTORYTABLE_IDNAME), F INDEX (PK_FILES_ID))), R INDEX (PK_HISTORYROW_IDROW)) PLAN (FAST_HISTORY NATURAL) А сколько различных значений у ID_USER и ID_COMP ???? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:15 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDenPLAN (FAST_HISTORY NATURAL) так я и знал! Ну, значит, вложенный запрос выполняется 25 тысяч раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:15 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
kdv ArtDenPLAN (FAST_HISTORY NATURAL) так я и знал! Ну, значит, вложенный запрос выполняется 25 тысяч раз. А что тут можно было ожидать чего-то другого ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:19 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
m7m, 900 и 1200 Получается, я ошибся. В остальных справочных таблицах не несколько десятков, в несколько сотен записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:20 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
В общем, нужны рекомендации. При необходимости могу немного поменять структуру базы, если другими способами невозможно что либо сделать. PS: SQL-запрос должен быть без расширений FB, чтобы он отрабатывал на других СУБД ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:24 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, тут ничего удивительного. Как я уже говорил HASH OUTER JOIN ФБ пока не умеет. Ты ещё и дополнительный геморрой себе отрастил тем, что не сделал искусственный ПК в fast_history. Если бы он был можно было бы повоевать вот так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
не факт что было бы быстрее, но мало ли. Вот это Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
сколько выполняется? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:25 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Симонов Денис сколько выполняется? Ждал почти 20 минут. Не дождался, прибил. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:46 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen m7m, 900 и 1200 и получается около 5000 дубликатов в таблице history на каждое значение и вот этот кусок H INDEX (FK_HISTORY_IDCOMP, FK_HISTORY_IDUSER) совсем не вселяет оптимизма Возможно чуток может помочь избавление в плане от одного из этих индексов Возможно немного больше поможет составной индекс ID_COMP,ID_USER ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 15:57 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Симонов Денис Вот это Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
сколько выполняется? Денис возможно все-же время выполнения этого запроса Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
более интересно тем более что именно его и надо оптимизировать Хотя что тут интересного по сообщениям и так ясно что он тормозит ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 16:07 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
m7m, 1. Запустил Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Жду. +0 в правильном месте? План получился PLAN JOIN (JOIN (JOIN (T INDEX (FK_HISTORYTABLE_IDNAME), F INDEX (PK_FILES_ID)), R INDEX (FK_HISTORYROW_IDTABLE)), H INDEX (FK_HISTORY_IDROW)) PLAN (FAST_HISTORY NATURAL) 2. Составными индексами уже наигрался. Они дали выигрыш в других запросах с меньшим количеством join. Могу ещё раз попробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 16:10 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
m7m Денис возможно все-же время выполнения этого запроса более интересно тем более что именно его и надо оптимизировать Хотя что тут интересного по сообщениям и так ясно что он тормозит Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
0.03 sec ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 16:17 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen m7m Денис возможно все-же время выполнения этого запроса более интересно тем более что именно его и надо оптимизировать Хотя что тут интересного по сообщениям и так ясно что он тормозит Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
0.03 sec План какой? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 16:38 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, чую у вас в мусор в fast_history накопился при неудачных удалениях Код: sql 1.
А потом оптимизировать надо, а не сам delete Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 17:39 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen 0.03 sec 25000 * 0.03 /60=12.5 минут ну пусть 15 минут что-то у меня в голове не складывается может быть действительно Симонов Денис чую у вас в мусор в fast_history накопился при неудачных удалениях ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 18:31 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, gstat -r -t fast_history ? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 19:11 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Вот Код: plaintext 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.
Данные свежезагруженные. Реально в таблице FAST_HISTORY нету данных для удаления. Т.е. запрос должен отработать вхолостую. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 19:24 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
m7m 0.03 sec План какой? PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN JOIN (H INDEX (FK_HISTORY_IDCOMP, FK_HISTORY_IDUSER), R INDEX (PK_HISTORYROW_IDROW), T INDEX (PK_HISTORYTABLE_IDTABLE), F INDEX (PK_FILES_ID)) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 20:07 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen m7m 0.03 sec План какой? PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN (FAST_HISTORY NATURAL) PLAN JOIN (H INDEX (FK_HISTORY_IDCOMP, FK_HISTORY_IDUSER), R INDEX (PK_HISTORYROW_IDROW), T INDEX (PK_HISTORYTABLE_IDTABLE), F INDEX (PK_FILES_ID)) Точно такой -же как и при удалении мои фантазии иссякли :( Надо ждать более знающих ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 20:10 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Подропал всё лишнее и обфусциоровал словари. Вот реальные данные для тестирования: https://drive.google.com/file/d/1FIEUiyUU9EuF77nDRzg5wtgeLxTm0tFb/view?usp=sharing Пароль на архив - 123 Буду рад любым рекомендациям Напоминаю, что дико тормозит запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 09:06 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, курил вчера вечером на тестовых данных сгенерированных IBExpert. Пока успехов нет (( ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 09:30 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
execute block позволяет до 16 сек сократить время, но насколько я понимаю требуется совместимость запроса с другими СУБД... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:29 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ну или на стандартный MERGE переписать, там тоже 16 сек выходит. Но для этого надо на ФБ3 перейти. И не уверен, что PG поддерживает MERGE ... DELETE. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:45 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
пусть побудут эти варианты для разнообразия. Они под 3-ку заточены, но первый можно адаптировать под 2.5. Оба дают 16 сек. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:55 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
dimitr, а как написать MERGE для удаления не существующих? Он вроде DELETE делает только для WHEN MATCHED ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:57 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
да, я для удаления существующих написал. Невнимателен, пардон. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:59 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
dimitr, По моему это не совсем то, у него всё-таки NOT EXISTS ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 10:59 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
даже "совсем не то", я бы сказал :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 11:00 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, У меня получилось убыстрить через промежуточную таблицу Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Заполнение таблицы ~13 сек Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Запрос практически мгновенно Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Сгенеренные данные: Код: powershell 1. 2. 3. 4. 5.
Остальные таблицы по 100 записей. P.S. Надеюсь, ничего не перепутал. С уважением, Polesov. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 12:38 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen, кстати fast_history это ведь хранимый агрегат? Если да, то может и правда не надо заморачиваться с удалением не существующих, а просто удалять всё и заполнять заново. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 13:00 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
UPD На предоставленных данных: Вставка в промежуточную таблицу ~16 сек Запрос с select ~94 мсек Запрос с delete ~109 мсек ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 13:03 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Симонов Денис кстати fast_history это ведь хранимый агрегат? Если да, то может и правда не надо заморачиваться с удалением не существующих, а просто удалять всё и заполнять заново. Так раньше и происходило. Раз в сутки около часа ночи запускался скрипт, который делал полный delete, а потом её заполнял, запросом один-в-один похожим на запрос от Polesov: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
В какой-то момент мне показалось, что это не правильно - всё грохать и заполнять данные. И я переписал всё это на такой вариант: Код: sql 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.
Delete удаляет из fast_history только записи, который там быть не должно, а Insert довставляет те, которые могли случайно не вставиться в течение суток. На моё удивление в первую же ночь лог показал, что запрос на удаление повис. Слава богу пользователям это не ушло. Причём к insert-у нету претензий. Он отрабатывает за минуту на неразогретой базе и 20 секунд на разогретой, что меня полностью устраивает. Вот сейчас думаю, что же делать со всеми этими запросами. А fast-таблиц у меня дофига... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 14:24 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen Вот сейчас думаю, что же делать со всеми этими запросами. А fast-таблиц у меня дофига... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 14:35 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
hvlad, select distinct сильно ест дисковое пространство, если в результате запроса есть длинные поля (varchar), а записей в таблице очень много. Свободного места может и не хватить. Для запроса, который я привёл, это не критично (всего 5 млн записей и нету varchar), но есть и другие fast-таблицы. В общем, думаю. Возможно что некоторые таблицы я буду заполнять через полный delete + insert, а часть через хитрый delete + хитрый insert. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 15:34 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Если фаст-таблицы это что-то типа кэша-агрегатов, то мне кажется, разумно удалять тогда же, когда в них записи обновляются. Т.е. с помощью MERGE можно залить новые/обновить какой-то признак актуальности в существующих. Второй командой удалить неактуальные по этому признаку. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 15:45 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Глянул здешний список форумов, посчитал СУБД. Вместе с античностью хватает пальцев двух ног. Таки может дешевле написать для каждой нормальное решение - лефт джойн и удаление по null в хранимке? В конце концов, даже если сделать так с клиента, будет на несколько порядков быстрей, чем выполнение подзапроса для каждой записи. Как говорится, вам шашечки или ехать? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2020, 19:28 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Даже Деда разбудили, ироды. Нет, чтобы тикет соответствующий создать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2020, 00:28 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка В конце концов, даже если сделать так с клиента, будет на несколько порядков быстрей, чем выполнение подзапроса для каждой записи. Самое смешное, что так и пришлось сделать. Оказалось, что не только fb тупит на таких запросах ... |
|||
:
Нравится:
Не нравится:
|
|||
08.03.2020, 12:58 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
Vlad F, тикет о HASH OUTER JOIN зарегистрирован уже давно. Надеюсь хотя бы это мы увидим ближайшее время. Тут по идее ещё нужны тикеты о необходимости выполнять EXISTS/IN как semi join, а NOT EXISTS/NOT IN как anti join. Тогда будет больше вариантов оптимизации для таких запросов. И об этом ДЕ тоже известно, а вот когда руки дойдут это уже другой вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.03.2020, 13:09 |
|
where not exists сильно тормозит
|
|||
---|---|---|---|
#18+
ArtDen Оказалось, что не только fb тупит на таких запросах Естественно. Тут ведь какое дело. Все реляционные СУБД - идеологически инструмент работы с множествами. Заточены под их объединение-пересечение. И в плане модели хранения данных и в плане их использования. Начиная прямо со стандарта. Соответственно, усилия при созданиях реализаций стандарта направлены преимущественно на оптимизацию работы с множествами. И разработчик прикладухи на этом инструменте должен думать в первую очередь об эффективном использовании сильных сторон инструмента для выделения подмножества данных, над которыми должно быть выполнено какое-то действо, а не о самом действе, не запрягать телегу впереди коня. А в плане точечных уколов Btrieve Record Manager уделает любую РСУБД как дитё. Вот с ним и думать по другому надо, в первую очередь о действе. В общем, с Международным Праздником Выноса Ёлок, мужики. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.03.2020, 15:08 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1560419]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
144ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
81ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 286ms |
0 / 0 |