|
|
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
Разбираясь в причинах тормознутости одного изх своих скриптов, обнаружил, что причиной является выбор (причем не всегда) неоптимального (с моей точки зрения) плана запроса при внешнем объединении двух таблиц. Что-бы было о чем говорить я написал тестовый запрос, на котором ситуация видна: Итак: две таблицы big_table, small_table, кол-во записей в которых оличается на 1-2 порядка. Таблицы содержат два поля "rлюч" и "значение".В обеих содержатся уникальные значения, часть которых в обеих таблицах может пересекаться. Надо сделать с этими таблицами внешнее соединение по ключу. В записях, где ключи совпадают, значение брать из small_table, иначе значение брать той таблицы, ключ которой имеется в записи. Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. NESTED LOOP FULL OUTER JOIN - и на обе таблицы SEQUENTAL SCAN что совсем неоптимально. Если зпдпть на обе таблицы Primary KEY, то система может выбрать MERGE JOIN. Играясь параметрами мне ни разу не удалось добиться выбора HASH JOIN. Иногда, даже при наличии индексов необходимо хинтовать, что бы избежать NESTED LOOP FULL OUTER JOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 13:57 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
ASA 9.0.2.2542 кэш 32-256 мб, P4 2400 (Hyper Trading), СУБД разрешено использование обоих процессоров. БД на 2 кб страницу, хотя сервер запущен на 8 кб страницу (используются другие БД). Выполнил скрипт создания и заполнения таблиц. Отработал менее секунды, в таблицы как и полагается занеслось 10 000 и 100 записей. Выполнил запрос - 0,266 сек, по плану запроса стоит сортировка обоих таблиц по b_id и s_id во временные таблицы с генерацией поля связи $rowid, которые потом соединяются через алгоритм "Full Outer Merge Join (full outer join)", после которого во временную производится сортировка по вычисляемым полям запроса в времянку и возвращается результат на 10 000 записей. Вполне нормальный план и нормальное время выполнения с моей точки зрения. Прилагаю XML версию плана запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 16:20 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
Переписал чуть запрос, чтобы быстрее работали вычисления: Код: plaintext 1. 2. 3. 4. 5. 6. Повесил на big_table первичный ключ. План запросов не поменялся. Сделал первичные ключи таблиц кластерными и перестроил их - план запросов не поменялся. В общем говоря добиться "NESTED LOOP FULL OUTER JOIN" мне так и не удалось. СУБД за время всех экспериментов так и не слезла с минимально выделенных 32 мб. Добиться HASH соединения на таком обьеме и не удастся, так как овчинка выделки не стоит - ширина big_table - 8 байт, что слишком мало весит для 10000 записей и спокойно помещается полностью в кэш. Hash алгоритмы на самом деле очень сильно напрягают процессор и если можно обойтись кэшем и Work Table, то СУБД пойдет этим путем: Код: plaintext 1. 2. Так что смотрите план, который я поместил и сравнивайте со своим. Может быть дело в настройках БД или сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 16:40 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
У меня Cel2.5 WinXP Home. Под сервер выделяется 20-64Мб. Все остальное одинаковое. Теперь интересное: Тот же скрипт, который работал через JNLFO, запускаю еще раз, и получаю ваш план. Запускаю еще раз - снова JMFO, снова запускаю несколько раз - все нормально. И где-то на 5-1 шестой запуск - снова JNLFO. Т.е выбор плана, на незагруженном ничем сервере, на одном и том же запросе меняется. ASCRUS, попробуйте позапускать скрипт несколько раз. Попробуйте увеличить кол-во строк в обеих таблицах в раз 10, т.е 100тыс и 1 одна тыс строк соответсвенно. Жду результатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2005, 17:37 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
Очищаю таблички: Код: plaintext 1. Заполняю их на 100000 и 1000 соответствующе: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Execution time: 0.015 seconds Проверяем кол-во записей: Код: plaintext 1. вернулось значение 100000. Код: plaintext 1. вернулось значение 1000. Выполняю запрос: ISQLExecution time: 2.109 seconds вернулось 100000 записей. План запроса такой же - с "Full Outer Merge Join (full outer join)". Хорошо, добавляю в big_table еще 100000 записей (причем опять же с b_id начиная с значения 1) - теперь в таблице каждая запись дублируется. Первичного ключа на нее нет. ISQLExecution time: 2.219 seconds Выполняю запрос: ISQLExecution time: 5.125 seconds План запроса теперь с "Full Outer Nested Loops Join (full outer join)" - то есть идет скан обоих таблиц, обьединение по этому алгоритму, далее сортировка во времянку и выдача клиенту. Возвращено 200000 записей. Прилагаю этот план запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 10:04 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
Далее вешаю индекс: Код: plaintext Выполняю запрос - опа - план с MERGE. Следующее выполнение - план с NESTED LOOPS. Соотвествующе делаю вывод - пока записей мало или в кэше, то используется MERGE, если в кэше их всех нет (то есть не помещаются), то используется NESTED LOOPS. Как только я кол-во записей увеличил до 200000, ASA решила подобрать памяти до 48 мб. Теперь пишем эквивалент Вашему запросу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Делает он то же самое, так же возвращает 200000 записей, естественно план запроса другой (прилагается ниже). Однако здесь я явно указал, что выбрать все записи из small_table, помноженное на кол-во таких же записей в big_table и присоединить к ним записи из big_table, которых нет в small_table. Если бы по условию задачи нам нужно было бы выбрать все записи из small_table (т.е. игнорируя дублирующиеся похожие в big_table) и только те, которые из big_table, которых нет в small_table, то тогда запрос был бы еще легче: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 10:29 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
А где все "прилагаемые" планы запросов ? Я что-то не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2005, 14:20 |
|
||
|
Стратегия соединения Full Outer Join
|
|||
|---|---|---|---|
|
#18+
MasterZivА где все "прилагаемые" планы запросов ? Я что-то не вижу. Они прилагаются в присоединенных XML файлах для сообщений. В ASA графические планы запросов из ISQL можно сохранять в XML файлы и открывать их в ISQL - очень удобно, наглядно, а главное со всеми опциями сервера, БД и статистикой - между прочим это описано в FAQ :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2005, 15:54 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=111&tid=2013981]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 233ms |
| total: | 397ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...