#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функций.