Блог

Главная - Вопросы по программированию - Постоянное сканирование в плане запроса, приводящее к массивной ошибке оценки мощности

Постоянное сканирование в плане запроса, приводящее к массивной ошибке оценки мощности

#sql-server #tsql #sql-execution-plan

#sql-server #tsql #sql-execution-plan

Вопрос:

Мой запрос использует GETDATE() и, следовательно, получает некоторые операторы постоянного сканирования в план запроса.

Предполагаемое количество строк на внешнем входе внутреннего соединения равно 2, но фактическое количество строк равно 262442.

Я считаю, что при таком огромном количестве строк объединение во внутреннем цикле будет очень неэффективным. Ошибка оценки также приводит к утечке базы данных tempdb в операторе сортировки.

Могу ли я что-нибудь сделать? (Подсказки по запросу, статистика и т.д.?)

Вот весь план запроса, включая SQL.

Комментарии:

1. Какой запрос вы на самом деле выполняете? Использование Вставить план было бы более полезным, чем изображение.

2. В дополнение к комментарию @Larnu, добавьте DDL с индексами к вашему вопросу, поскольку конечной целью, вероятно, является повышение производительности запроса. Оценка мощности — это только часть картины.

3. Мои две догадки — устаревшая статистика, дающая неправильные оценки, или кэширование с перехватом параметров в плохом плане

4. Кажется, что виновником является применение функций к столбцам: AND datepart(year,[MTMS_Staging_Dev].[MTMS].[ORDS].[ORDSDATE_ENT] as [ORDS].[ORDSDATE_ENT]) >= datepart(year,getdate())-(2) AND datepart(year,[MTMS_Staging_Dev].[MTMS].[ORDS].[ORDSDATE_ENT] as [ORDS].[ORDSDATE_ENT]) <= datepart(year,getdate())

5. Я бы ожидал гораздо лучших оценок (и, возможно, использования индекса) путем рефакторинга, чтобы избежать применения DATEPART функций.