Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Помогите гуру. Что то подкинул бизнес задачку... Запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Таблицы ACS, OP и VAT - маленькие. Таблица ACT - большая, более 1.3млрд записей. Задача выбрать данные по ней за 3 дня, ну от текущей даты скажем. Почему то происходит Table Scan этой большой таблицы ACT, хотя по идее - не должно. Этот скан, разумеется, дико замедляет запрос, перебрать миллиард записей то... Куда рыть, не совсем понимаю, оптимизатор говорит про неоптимальный Hash Match, дескать Probe Residual, неявное преобразование и т.д. Но то неважно, соединить тысячи строк, это же не миллиард перебрать... План запроса больше 150 кб, залил на гугл диск: https://drive.google.com/open?id=17wE-6Dtu-g_ehTgAk3SiWucVj1DgLXRF ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 15:23 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
отбери во времянку с ACT все подходящее под твое условие WHERE (SA.DB >= CONVERT(date,DATEADD(DAY, -3, getdate())) AND SA.DB < CONVERT(date, GETDATE())) AND SA.STOREID > 3 вот ето все обьяви в переменную до выборки CONVERT(date,DATEADD(DAY, -3, getdate())) ,а уж патом джойнь и группируй ЗЫ план не читал не дотсупен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 15:28 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Возьми MIN(SA.UNIQ) с правильными датами, а потом выбери все TA с CSID большим чем она. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 15:38 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAlПочему то происходит Table Scan этой большой таблицы ACTПотому что hast match и таблица на внутреннем входе. Индекс нужен подходящий для dbo.ACT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:00 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Maxx, план расшарил. А почему в переменную, в чем тут тайный смысл? WHERE то работает по маленькой таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:06 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
invm, индексы для ACT есть по полю CSID и по полю UNIQ. Но оба - некластеризованные ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:07 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAl, В АСТ есть дата? фильтруй по ней в джойне ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:13 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
vborets, не вариант Грубо схема. ACS - заголовок документа, ACT - строки документа. Поле даты в ACT есть, но строк в ACT 1,3млрд, в ACS - пару млн. Фильтровать выгодней в ACS... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:29 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAlinvm, индексы для ACT есть по полю CSID и по полю UNIQ. Но оба - некластеризованныеДля начала статистику обновите. Желательно с fullscan. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:32 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAlvborets, не вариант Грубо схема. ACS - заголовок документа, ACT - строки документа. Поле даты в ACT есть, но строк в ACT 1,3млрд, в ACS - пару млн. Фильтровать выгодней в ACS... invm ответил почему. ваши авториндексы для ACT есть по полю CSID и по полю UNIQ. Но оба - некластеризованные не нравятся. Можете прибить по UNIQ но получите лукап ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:33 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Нужен индекс по ACT.CSID + хинт FORCESEEK (часто оптимизатор даже при нормальном индексе делает SCAN по индексу). Но т.к. данных выбирается всего за 3 дня, лучше ему это указать явно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 16:53 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Ну так то автоматическая статистика обновляется в 16м скл неплохо... Статистику по индексам, да, давненько не обновлял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2018, 17:28 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Ну и да, в итоге банальное устаревание статистики по индексу. Пересчитал частично за ночь с фулскан, план запроса сразу поменялся, индекс заработал. Ох тыж, как бы еще придумать, чтобы за ночь обновление статистики проходило, а то ведь по одной этой большой таблице это почти на сутки, а по всей БД - двое... Наверное стоит использовать sp_updatestats? Конечно, как там сервер решит, кто достоин обновления, вопрос, но работает быстрее. Или же, при ребилде индексов, статистика ведь тоже обновляется. Тогда выходит, выгодней ребилд индексов делать по отдельным таблицам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2018, 10:15 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAl, а auto update не включен что ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2018, 10:17 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAlОх тыж, как бы еще придумать, чтобы за ночь обновление статистики проходилоВозможно вам поможет секционирование и инкрементальное обновноление статистики. JohnAlТогда выходит, выгодней ребилд индексов делать по отдельным таблицам.Одумайтесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2018, 10:52 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
JohnAlvborets, не вариант Грубо схема. ACS - заголовок документа, ACT - строки документа. Поле даты в ACT есть, но строк в ACT 1,3млрд, в ACS - пару млн. Фильтровать выгодней в ACS...Бред! Коллега, вы не правы! Любые фильтры напрямую по огромным таблицам всегда лучше чем какие либо фильтры через джойны, потому что: а) При джойне данные из большой таблицы дергаются по ID единичными index seek. В то время как BETWEEN фильтр по дате по основной таблицы пройдет в один seek по первой дате + scan до конечной даты, с полным префетчем и максимально возможной (учитывая фрагментацию) скоростью вычитки с диска. б) Погрешности статистики при джойне всегда хуже чем при прямом фильтре. В 16ом конечно стало лучше, но до совершенства далеко. Вы про это думаете что серверу нужно отфильровать лишние 1,3млрд минус 5 тысяч строк, и это куча работы, а должны думать как серверу нужно выбрать 5 тысяч строк по индексу и пофигу из таблицы какого размера. На самом деле даже если бы там было 100 млрд строк, то скорость выборки по индексу изменилась бы максимум на 1-2 дополнительных чтения или несколько миллисекунд. Для этого собственно индексы и нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2018, 22:21 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
invmJohnAlТогда выходит, выгодней ребилд индексов делать по отдельным таблицам.Одумайтесь.Да можно и отдельные статистики с фуллсканом обновлять, в чем проблема то? Зачастую на таблице автоматом создается статистик как количество полей + индексов + если еще вручную кто сделал, большая часть из которых вообще никому не сдалась и зачем их все обновлять с фуллсканом? Каждая колоночная статистика это почти гарантированный table scan, в то время как индексная статистика это всего лишь index scan. Почти наверняка ТСу хватило бы обновить статистику по TA.CSID, SA.UNIQ, TA.OPCODE и OP.OPCODE. Там эстимейт выдает 227 миллионов строк при реальных 80. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2018, 22:32 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
MindЛюбые фильтры напрямую по огромным таблицам всегда лучше чем какие либо фильтры через джойны, потому что: Совершенно верно. Именно поэтому я и предлагал сначала вывести из большой таблице некий дамп, а потом уже этот дамп джойнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2018, 02:46 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
MindДа можно и отдельные статистики с фуллсканом обновлять, в чем проблема то?Никаких. Только ТС вместо этого хочет перестраивать индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2018, 09:28 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Mindinvmпропущено... Одумайтесь.Да можно и отдельные статистики с фуллсканом обновлять, в чем проблема то? Зачастую на таблице автоматом создается статистик как количество полей + индексов + если еще вручную кто сделал, большая часть из которых вообще никому не сдалась и зачем их все обновлять с фуллсканом? Каждая колоночная статистика это почти гарантированный table scan, в то время как индексная статистика это всего лишь index scan. Почти наверняка ТСу хватило бы обновить статистику по TA.CSID, SA.UNIQ, TA.OPCODE и OP.OPCODE. Там эстимейт выдает 227 миллионов строк при реальных 80. Можно конечно. Просто вопрос автоматизации. Ручками выбрать статистики то - несложно, но таблиц в БД две сотни. Найду подходящий скрипт по апдейтам, тогда уж... Если кто подскажет, был бы благодарен. А то вот нагуглил: Код: 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. А оно выводит не все таблицы ((( Фильтры хороши, но только когда есть индексы. В большой таблице АСТ индекса по дате - нет, есть только по id. Добавлять индексы в эту таблицу не особо возможно. Очень много интенсивной вставки данных, как пакетной так и нет. Чтения - намного меньше. Тут есть опасения, что накладные расходы от нового индекса превысят выгоды более быстрой работы отчета. На чтение, для отчетов, сделал снапшот с зеркала на другом сервере. Вот его терзают этими запросами. На боевой БД такие запросы - редкость, точнее стараемся их вывести на зеркальный сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2018, 15:14 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39648186&tid=1689672]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
| others: | 261ms |
| total: | 435ms |

| 0 / 0 |
