SQL-запрос занимает много времени при фильтрации последних строк

Question

У меня есть этот запрос SQL, но я обнаружил, что это может занять до 11 секунд. Я действительно запутался, потому что, когда я изменяю выбор даты на дату 2018 года, она мгновенно возвращается.

Вот запрос:

select
    cv.table3ID, dm.Column1 ,dm.Column2, mm.Column1, 
    convert(varchar, cv.Date, 107) as Date, 
    mm.table2ID, dm.table1ID, mm.Column2,
    count(ctt.table4ID) as Total
from
    table1 dm
inner join 
    table2 mm on mm.table2ID = dm.table1ID
inner join 
    table3 cv on cv.table3ID = mm.table2ID
left join 
    table4 ct on ct.table4CVID = cv.table3ID
inner join 
    table4 ctt on ctt.table4MMID = mm.table2ID
where
    ctt.table4Date >= '2019-01-19'
    and ct.table4CVID is null  
    and dm.Column1 like '%Albert%'
    and cv.Column1 = 39505 
    and cv.Status = 'A'  
group by
    cv.table3ID, dm.Column1 ,dm.Column2, mm.Column1, 
    cv.Date, mm.table2ID, dm.table1ID, mm.Column2

Я обнаружил, что когда я выполняю этот запрос с ctt.table4Date >= '2018-01-19', ответ мгновенный. Но с "2019-01-19" это занимает 11 секунд.

Первоначально, когда я обнаружил, что запрос занимает 11 секунд, я подумал, что это должно быть проблемой индексации, но я больше не уверен, имеет ли он отношение к индексу, так как он хорошо работает для более старой даты.

Я посмотрел на план выполнения запроса с разными датами, и они выглядят совершенно по-разному.

Есть мысли о том, почему это может происходить? Это как-то связано с обновлением статистики?

[Обновить]

Это изображение ниже - сравнение плана выполнения между 2018 и 2019 для table4 ctt. Согласно плану выполнения, это занимает 43% от стоимости оператора в 2018 году и 45% в 2019 году. Сравнение плана выполнения таблиц 4 ctt 2019 и 2018. Верхняя часть - 2019, нижняя - 208

Изображение здесь - сравнение плана выполнения снова для table4 как ct. То же самое здесь, верх - 2019, а низ - 2018. План выполнения таблицы 4 ct сравнения 2019 и 2018. Верх - 2019, низ - 208

[Обновление 2]

Вот планы выполнения SQL:

При использовании "2018-01-19" в качестве даты: https://www.brentozar.com/pastetheplan/?id=SyUh8xXQV

При использовании "2019-01-19" в качестве даты: https://www.brentozar.com/pastetheplan/?id=rkELW1Q7V

Answer 1

Проблема, скорее всего, заключается в том, что из других таблиц возвращается больше строк. Сканирование кластеризованного индекса, которое вы связали с вашим [обновлением], просто показывает поиск кластеризованного индекса.

Однако вы должны понимать, что число обращений к поиску по индексу составляет 144. Фактическое число прочитанных строк составляет 8 цифр, что вызывает медленный ответ.

Я предполагаю, что когда это будет работать хорошо для вас, фактическое количество выполнений в этой таблице будет равно 1. 144 убивает вас здесь; учитывая предикаты бедного поиска. Если вы знаете план запроса, который работает для вас, и индексы уже существуют для его резервного копирования, вам следует принудительно искать планы и давать явные подсказки для присоединения в определенном порядке.

редактировать

Взглянув на общие планы, изменение даты на 2018 работает для вас быстрее, поскольку SQL переключается на использование Hash Match вместо соединения цикла, учитывая объем обрабатываемых данных.