«Предупреждения: операция вызвала остаточный ввод-вывод» в сравнении с поиском по ключевым словам

Я видел это предупреждение в планах выполнения SQL Server 2017:

Предупреждения: Операция вызвала остаточный IO [sic]. Фактическое количество прочитанных строк было (3,321,318), но количество возвращенных строк было 40.

Вот фрагмент из SQLSentry PlanExplorer:

Чтобы улучшить код, я добавил некластеризованный индекс, чтобы SQL Server мог получить доступ к соответствующим строкам. Он работает нормально, но обычно в индексе слишком много (больших) столбцов. Это выглядит так:

Если я только добавляю индекс без включаемых столбцов, это выглядит так, если я принудительно использую индекс:

Очевидно, что SQL Server считает, что поиск ключа намного дороже, чем остаточный ввод-вывод. У меня есть тестовая установка без большого количества тестовых данных (пока), но когда код запускается в производство, он должен работать с гораздо большим количеством данных, поэтому я совершенно уверен, что нужен какой-то неклассированный индекс.

Действительно ли ключевые поиски настолько дороги , что при работе на твердотельных накопителях мне приходится создавать полные индексы (с большим количеством включаемых столбцов)?

План выполнения: https://www.brentozar.com/pastetheplan/?id=SJtiRte2X Это часть длительной хранимой процедуры. Ищите IX_BatchNo_DeviceNo_CreatedUTC.

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

Как правило, не следует предполагать, что отдельные оценки затрат будут сильно коррелировать с производительностью времени выполнения для конкретной конфигурации оборудования. Суть оценки состоит в том, чтобы позволить оптимизатору сделать осознанный выбор между физическими альтернативами-кандидатами для одной и той же логической операции.

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

По моему опыту (и мнению), оптимизатор запросов SQL Server стоит поисков выше, чем я бы предпочел. Это во многом похмелье со времен, когда случайный физический ввод-вывод был намного дороже по сравнению с последовательным доступом, чем это часто бывает сегодня.

Тем не менее, поиск может быть дорогим, даже на SSD, или, в конечном счете, даже при чтении исключительно из памяти. Пересечение структур b-дерева не бесплатно. Очевидно, что стоимость растет, как вы делаете больше из них.

Включенные столбцы отлично подходят для рабочих нагрузок OLTP с интенсивным чтением, где имеет смысл компромисс между использованием пространства индекса и стоимостью обновления по сравнению с производительностью чтения во время выполнения. Есть также компромисс, чтобы рассмотреть вокруг стабильности плана . Полностью охватывающий индекс позволяет избежать вопроса о том, когда именно стоимостная модель оптимизатора может перейти от одной альтернативы к другой.

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

В вопросе комментарий вы добавили:

Вы говорите мне, что SQL Server не знает стоимость остаточного ввода-вывода?

Нет, оптимизатор учитывает стоимость остаточного ввода-вывода. Действительно, что касается оптимизатора, предикаты без SARGable оцениваются в отдельном фильтре. Этот фильтр проталкивается в испрашивать или сканирование в качестве остатка во время поста-оптимизация переписывает.