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

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

0 голосов
/ 21 января 2019

У меня есть этот запрос 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 секунд, я подумал, что это должно быть проблемой индексации, но я больше не уверен, имеет ли он отношение к индексу, так как он хорошо работает дляболее старая дата.

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

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

[Update]

Это изображение ниже представляет сравнение плана выполнения между 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

1 Ответ

0 голосов
/ 21 января 2019

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

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

enter image description here

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

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

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

...