|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Добрый день, коллеги! Есть, скажем так, словарик: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Сервер: х64 2.5.6.27020 Superserver Выполняю в нем поиск по нескольким словам разными способами: JOIN Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
План PLAN SORT (MERGE (SORT (JOIN (IW3 INDEX (INDEXER_WORDS_IDX1), IFL3 INDEX (FK_INDEXER_FILES_1))), SORT (JOIN (IW2 INDEX (INDEXER_WORDS_IDX1), IFL2 INDEX (FK_INDEXER_FILES_1))), SORT (JOIN (IW INDEX (INDEXER_WORDS_IDX1), IFL1 INDEX (FK_INDEXER_FILES_1))))) ------ Информация о производительности ------ Время подготовки запроса = 0ms Время выполнения запроса = 3s 230ms Среднее время на получение одной записи = 100,94 ms Current memory = 341 745 248 Max memory = 347 191 168 Memory buffers = 20 480 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 36 079 IR (индексные чтения iw=indexer_words, if=indexer_files) iw=441 if=17429 EXISTS Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
План PLAN JOIN (IW2 INDEX (INDEXER_WORDS_IDX1), IFL2 INDEX (FK_INDEXER_FILES_1)) PLAN JOIN (IW3 INDEX (INDEXER_WORDS_IDX1), IFL3 INDEX (FK_INDEXER_FILES_1)) PLAN SORT (JOIN (IW1 INDEX (INDEXER_WORDS_IDX1), IFL1 INDEX (FK_INDEXER_FILES_1))) ------ Информация о производительности ------ Время подготовки запроса = 0ms Время выполнения запроса = 19s 594ms Среднее время на получение одной записи = 612,31 ms Current memory = 341 744 048 Max memory = 347 191 168 Memory buffers = 20 480 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 38 754 241 IR iw=3 868 801 if=15 455 282 EXECUTE BLOCK Код: 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.
План PLAN JOIN (IW2 INDEX (INDEXER_WORDS_IDX1), IFL2 INDEX (FK_INDEXER_FILES_1)) PLAN JOIN (IW3 INDEX (INDEXER_WORDS_IDX1), IFL3 INDEX (FK_INDEXER_FILES_1)) PLAN SORT (JOIN (IW1 INDEX (INDEXER_WORDS_IDX1), IFL1 INDEX (FK_INDEXER_FILES_1))) ------ Информация о производительности ------ Время подготовки запроса = 16ms Время выполнения запроса = 4s 602ms Среднее время на получение одной записи = 143,81 ms Current memory = 341 756 368 Max memory = 347 191 168 Memory buffers = 20 480 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 8 943 775 IR iw=998 835 if=3 460 451 Вопрос: почему так отличаются планы выполнения и использование ресурсов? Мне кажется, что exists и execute block технически должны выполняться одинаково. Я где-то ошибаюсь? Для некоторых запросов execute block ощутимо выигрывает по времени даже у join. В общем я потерялся.... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 15:46 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57, с выборками из execute block и процедур не забывай делать fetch all. А то по suspend получил первый блок записей за 4 секунды, и обрадовался. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 15:53 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
kdv, не не это я конечно учел. Там просто всего 20 записей. Они по-любому фетчатся все. p.s. в indexer_words около 370 000 записей, а в indexer_files около 24 000 000 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 15:55 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57, а чего это у тебя file_id не индексирован? Неудивительно что тормоза есть, т.к. соединение использует MERGE JOIN многократно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 16:35 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов Денис, хотя... не поможет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 16:41 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов Дениса чего это у тебя file_id не индексирован?дык я тоже подумал:"а чего это он у меня не индексирован". Проиндексировал...и сервер ушел в себя. Не дождался - срубил (остановил службу). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 16:44 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57..и сервер ушел в себяВ смысле при выполнении запроса join. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 16:45 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Ну и file_id уникальных значений около 28 000 из 24 000 000. Не самый лучший индекс наверное. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 16:46 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57Мне кажется, что exists и execute block технически должны выполняться одинаково. Я где-то ошибаюсь? Показалось, что таки ошибаюсь и должно быть так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Но результат еще хуже. Время: 41 сек. iw=978 000 if=52 400 000 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:05 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57, exists здесь будет всегда хуже JOIN, т.к. нет индекса. EXISTS не умеет выполняться с помощью HASH OUTER SEMI JOIN. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:13 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов ДенисBarmaley57, exists здесь будет всегда хуже JOIN, т.к. нет индекса. EXISTS не умеет выполняться с помощью HASH OUTER SEMI JOIN.Да, я это понимаю (надеюсь))) Тут вопрос в другом: авторМне кажется, что exists и execute block технически должны выполняться одинаково ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:16 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Ну и вот это авторДля некоторых запросов execute block ощутимо выигрывает по времени даже у join ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:19 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57Тут вопрос в другом: авторМне кажется, что exists и execute block технически должны выполняться одинаково не совсем. distinct делается уже после exists, а в execute block до. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:25 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов ДенисBarmaley57Тут вопрос в другом: пропущено... не совсем. distinct делается уже после exists, а в execute block до.Дык а здесь 19796420 тоже что-ли после? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 19:28 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57, ради интереса проверь вот этот запрос Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2016, 21:15 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов Денис, попробовал. Результат очень хороший: результатPLAN MERGE (SORT (SORT (JOIN (T4 IW INDEX (INDEXER_WORDS_IDX1), T4 IFL INDEX (FK_INDEXER_FILES_1)))), SORT (SORT (JOIN (T3 IW INDEX (INDEXER_WORDS_IDX1), T3 IFL INDEX (FK_INDEXER_FILES_1)))), SORT (SORT (JOIN (T2 IW INDEX (INDEXER_WORDS_IDX1), T2 IFL INDEX (FK_INDEXER_FILES_1)))), SORT (SORT (JOIN (T1 IW INDEX (INDEXER_WORDS_IDX1), T1 IFL INDEX (FK_INDEXER_FILES_1))))) время ~200 мсек. Чтения такие же, как при join. Никогда не приходилось использовать синтаксис WITH [RECURSIVE]. Уже думал в эту сторону, но ты меня опередил. Спасибо за подсказку. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 12:30 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Barmaley57, запрос с CTE точно такой же, как и первый с JOIN. Разве что его приятнее читать :) Вот только в плане ты показал 4 таблицы, а не 3... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 12:55 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
hvladзапрос с CTE точно такой же, как и первый с JOIN.Не, соврал немного - с CTE дистинкты в каждом выражении есть. Но суть - та же ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 12:57 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
hvlad, я исходил из предположения, что с помощью дистинктов в каждом CTE уменьшу мощность множеств для соединения алгоритмом MERGE JOIN. Видимо не ошибся :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 13:08 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов Денис, В 3.0 ещё и HASH JOIN можно подключить, может ускорится. Не совсем кейс ТС, но иногда такие штуки через группировку можно быстро собрать. Код: sql 1. 2. 3. 4. 5. 6.
Записей ~800'000 всего, и 1109 во всех результатах В лоб Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
через group by Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
через hash join (FB3.0) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 14:55 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
afgmВ 3.0 ещё и HASH JOIN можно подключить, может ускорится. Пока что в 3.0 HASH JOIN работает вместо MERGE JOIN. Никакого выбора по стоимости нет, да и заставить соединять MERGEм тройку нельзя. В теории MERGE может быть быстрее HASH если множества и так отсортированы по соединяемым полям, и если исключить двойную сортировку. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 15:07 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
hvladBarmaley57, запрос с CTE точно такой же, как и первый с JOIN. Разве что его приятнее читать :) Вот только в плане ты показал 4 таблицы, а не 3...По скорости выполнения получается, что не такой же. План я не тот привел. Каюсь. Просто сразу еще попробовал на 4-х соединениях. Симонов Денис я исходил из предположения, что с помощью дистинктов в каждом CTE уменьшу мощность множествя вот как раз тоже самое хотел сделать, только не вкуривал как afgmтакие штуки через группировку можно быстро собрать.это у меня был первоначальный вариант. Работал и правда очень шустро, но потом пришлось от него отказаться из-за доп.условий поиска. Отцы, спасибо всем за участие. С вами приятно иметь дело) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 15:31 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Симонов ДенисПока что в 3.0 HASH JOIN работает вместо MERGE JOIN. Никакого выбора по стоимости нет, да и заставить соединять MERGEм тройку нельзя. Это порой печалит, согласен. Hash join пока в начале своего внедрения в FB, и для left join тоже появится, надеюсь. Я вот ещё не нашёл почему в FB нет merge LEFT join... Симонов ДенисВ теории MERGE может быть быстрее HASH если множества и так отсортированы по соединяемым полям, и если исключить двойную сортировку. Тут всё не так однозначно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 15:37 |
|
Вопрос по "плановому хозяйству"
|
|||
---|---|---|---|
#18+
Дабы не создавать ненужной темы, спрошу здесь: правильно я понимаю, что остановить долгоиграющий запрос кроме как черезжопным методом с помощью генератора или путем удаления записи из MON$ нельзя? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2016, 13:31 |
|
|
start [/forum/topic.php?fid=40&msg=39329333&tid=1561902]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 265ms |
total: | 418ms |
0 / 0 |