Я видел это предупреждение в планах выполнения 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.
источник
sys.dm_exec_query_profiles, мы переоценим его исходя из фактических затрат и расчетных). Прекратите использовать оценочный% стоимости как некоторый абсолютный показатель стоимости - это относительно, и это часто на обед.Ответы:
Модель стоимости, используемая оптимизатором, - это модель . Как правило, он дает хорошие результаты в широком диапазоне рабочих нагрузок, в широком спектре конструкций баз данных, на широком спектре аппаратного обеспечения.
Как правило, не следует предполагать, что отдельные оценки затрат будут сильно коррелировать с производительностью времени выполнения для конкретной конфигурации оборудования. Суть оценки состоит в том, чтобы позволить оптимизатору сделать осознанный выбор между физическими альтернативами-кандидатами для одной и той же логической операции.
Когда вы действительно углубляетесь в детали, квалифицированный специалист по базам данных (со временем, потраченным на настройку важного запроса) часто может добиться большего успеха. В этом смысле вы можете рассматривать выбор плана оптимизатора как хорошую отправную точку. В большинстве случаев эта отправная точка также будет конечной точкой, поскольку найденное решение достаточно хорошее .
По моему опыту (и мнению), оптимизатор запросов SQL Server стоит поисков выше, чем я бы предпочел. Это во многом похмелье со времен, когда случайный физический ввод-вывод был намного дороже по сравнению с последовательным доступом, чем это часто бывает сегодня.
Тем не менее, поиск может быть дорогим, даже на SSD, или, в конечном счете, даже при чтении исключительно из памяти. Пересечение структур b-дерева не бесплатно. Очевидно, что стоимость растет, как вы делаете больше из них.
Включенные столбцы отлично подходят для рабочих нагрузок OLTP с интенсивным чтением, где имеет смысл компромисс между использованием пространства индекса и стоимостью обновления по сравнению с производительностью чтения во время выполнения. Есть также компромисс, чтобы рассмотреть вокруг стабильности плана . Полностью охватывающий индекс позволяет избежать вопроса о том, когда именно стоимостная модель оптимизатора может перейти от одной альтернативы к другой.
Только вы можете решить, стоят ли компромиссы в вашем случае. Протестируйте обе альтернативы на репрезентативной выборке данных и сделайте осознанный выбор.
В вопросе комментарий вы добавили:
Нет, оптимизатор учитывает стоимость остаточного ввода-вывода. Действительно, что касается оптимизатора, предикаты без SARGable оцениваются в отдельном фильтре. Этот фильтр проталкивается в испрашивать или сканирование в качестве остатка во время поста-оптимизация переписывает.
источник