Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
nvvMax_11111, 1c обмен на sql? интересно. "Правильный" - вообще не правильный. 1,6млрд циклов. Сколько каждый выполняется? 80000 изменений в РС - терпимо. Что если попробовать получить по каждому регистратору мин и макс периода и наложить условие по периоду + регистратору? Теперь кластерный возможно задействуется, без NL Да, 1С :) Выгружаем данных из основной базы в хранилище. Админы 1С сказали реализовать обмен по аналогии со стандартным, а мы и не против. Насчёт периода - да, это решит проблему. С некоторыми таблицами так и сделали, т.к. там индекс без периода не работал (возможно тоже дело в статистике, но я тогда про планы запросов знал меньше). Но такое решение мне не нравится - много лишних соединений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 03:00 |
|
||
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
Max_11111GlebanskiМеня вероятно запинают, но все ж интересно. Может быть, что SQL Server по какой-то причине стал полагать SORT слишком тяжеловесным? Изменится ли план, если внутри CTE заранее отсортировать данные? Ну с чем-то типа TOP 10000000 В меньшую сторону оценка может сдвинуться, а вот в большую - скорее всего нет. Как я понимаю: - если оптимизатор оценивает объём выборки в 100 строк, а вы говорите TOP 1000 - то оптимизатор проигнорирует это значение, ведь 100 - это максимум, который он ожидает. - Если оптимизатор даёт оценку в 1000 строк, а вы пишите TOP 100 - то оптимизатор с радостью изменит оценку на 100 строк. ? В 90% случаев при top оптимизатор будет использовать rowgoal, а оценка ожидания при этом считается как я тут описывал http://www.sql.ru/forum/1293108/strannaya-ocenka-kolichestva-strok?hl=, или я вас не понял. Для табличных переменных можно использовать OPTION (RECOMPILE) и estimated будет верный. Про SSIS не помню, так это или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 08:36 |
|
||
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
Max_11111, У вас таблица секционирована по _Period, а индекс нет. Если индекс секционировать и добавить _Period в условие соединения, возможно получите желаемое без дополнительных приседаний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 09:03 |
|
||
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
aleksrov, Спасибо, интересная статейка и ссылки в ней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 11:33 |
|
||
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
Max_11111, авторНасчёт периода - да, это решит проблему. С некоторыми таблицами так и сделали, т.к. там индекс без периода не работал (возможно тоже дело в статистике, но я тогда про планы запросов знал меньше). Но такое решение мне не нравится - много лишних соединений Достаточно посмотреть структуру кластерного (период+рег) и некласт(рег), чтобы понять что это наверно единственный способ получить наиболее производительный результат. Если это не так и вы уже все испробовали, то хоть расскажите, что в итоге получилось. Еще подсказка. Период в регистре в 99% равен дате документа, но бывают архитектурные отклонения. Незначительные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 22:01 |
|
||
|
Почему SQL Server игнорирует индекс в запросе
|
|||
|---|---|---|---|
|
#18+
Max_11111Статистику обновим, скорее всего на выходныхВряд ли поможет, если ошибается на JOIN. Как я уже сказал, у сервера проблемы с оценкой кардинальности по многоколоночным джойнам. Просто потому что он не отслеживает корреляцию значений между колонками в таблице. По сути у него есть две независимые гистограммы по ColumnA и ColumnB в одной таблице и тоже самое в другой. Отдельно по каждой колонке он посчитает кардинальность для джойна, а дальше идет усреднение для случая как если корреляции значений между колонками вообще никакой нет. Max_11111База крутится на 2014 SQL.А compatibility level то какой? Код: xml 1. Ради интереса попробуйте применить новый Cardinality Estimator опцией OPTION (QUERYTRACEON 2312). Может он лучше справится. Max_11111Критично. Запрос возвращает порядка 50000 строк, при этом оценочное количество на 4 порядка выше!То есть вы утверждаете что из первой таблицы этими 4-мя условиями выбирается 82 тысячи строк, а после джойна остается 50 тысяч? Т.е. таблица с ключами изменений содержит ключи которых нет в основной таблице, я вас правильно понял? Или может таки перестанете прокачивать наши телепатические скиллы и выложите актуальные планы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2018, 22:49 |
|
||
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1689209]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
3ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 320ms |
| 0 / 0 |
