Весь план запроса и запрос: https://www.brentozar.com/pastetheplan/?id=BkgbANxN4
Я борюсь с запросом, который использует много времени.Очевидная причина этого - неправильные оценки количества строк.Я пробовал индексировать и обновлять статистику, однако, похоже, я не решаю реальную проблему, так как запрос все еще идет на удивление медленно (я думаю, неверный индекс или статистика).
Мне нужна помощь в интерпретации этой информации, чтобы я мог помочь оптимизировать запрос.Какой индекс, какие функции DBCC или другие встроенные функции я должен запускать между выполнениями, чтобы гарантировать чистоту кэша, и тому подобное, чтобы избежать использования неправильных статистики и свежего нового?
Примеры будут
DBCC FREEPROCCACHE
UPDATE STATISTICS *table*
Еще одним узким местом того же запроса будут эти хеш-совпадения.Совпадение хэша в правом верхнем углу заканчивается за считанные секунды, в то время как левое, кажется, борется с последними 213 строками, которые используют много минут.Что я могу сделать, чтобы выяснить, в чем проблема в этих хэш-совпадениях?
Я также пытаюсь решить несколько разливов памяти в наших пакетных заданияхгде я могу только оптимизировать разлив памяти из одной таблицы.
У меня есть несколько сортировок и хеш-совпадений, где есть довольно длинные пробники и остатки, включая несколько таблиц или «выражений», которые, как я предполагаю, являются либо агрегированными, либоустанавливается пакетами служб SSIS.
Должен ли я сначала решить «первый» или «последний» разлив?Первый - это «верх из трех», а последний будет ближе всего к конечным узлам (операторам).Мне также интересно узнать о некоторых операторах, упомянутых ниже.
Можете ли вы объяснить, что означают термины в отношении описаний плана выполнения:
- Остаток сборки
- Остаток пробника
- Зонд хэш-ключей
Мне кажется, я понимаю следующие термины:
Порядок по : порядок, в котором оператору нужны данные в
Список вывода : какие данные оператор получает для вывода