Включенный столбец против отфильтрованного индекса

В настоящее время мы работаем с таблицей с именем tb_tranfers . Эта таблица имеет 40 миллионов строк и имеет размер ~ 26 ГБ (данные 11 ГБ, индексы 15 ГБ).

От 10 до 15% строк - это строки с мягким удалением ( DeletedDate не является нулевым). Приложение использует только те строки, для которых DeletedDate имеет значение null. Все запросы к этой таблице будут содержать предложение на этот счет.

В этой таблице 15 индексов. Отсутствующий индекс DMV содержит предложения по созданию индексов с DeletedDate в качестве включенного столбца.

Было бы полезно использовать отфильтрованный индекс WHERE DeleteDdate IS NULLпо всем 11 некластеризованным индексам? Или было бы лучше иметь столбец DeletedDate в качестве включенного столбца?

Да, изменение всех 11 NC-индексов для фильтрации indexes ( CREATE INDEX ... ON ... WHERE DeletedDate IS NULL) поможет. Таким образом, вы получаете два преимущества:

• Query Optimizer будет знать , что любая строка исходя из этих показателей уже действительно удовлетворяет ваши фильтры запроса на DeletedDate, поэтому он не будет иметь для поиска кластерного индекса перепроверить DeletedDate
• Все NC-индексы будут на 10-15% меньше по размеру, что потребует меньше памяти и меньше операций ввода-вывода для поиска.

Компромисс в том, что любой запрос, который присматривает за мягко удаленными строками (и должен быть какой-то запрос, в противном случае, почему строки существуют?) Не сможет использовать эти индексы NC.

Если вы ВСЕГДА используете DeletedDate IS NULLфильтр в своих запросах, то да, вы, скорее всего, увидите значительное увеличение производительности при добавлении фильтра.

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

Добавление его в качестве INCLUDEDполя было бы бесполезным . Поскольку вы всегда включаете его в фильтр (но, вероятно, никогда не добавляете его в список SELECT), на это поле никогда не будет ссылаться, если вы добавите его как INCLUDE.

Поскольку 85-90% строк с DeletedDate имеют значение NULL, маловероятно, что селективность индекса, состоящего только из DeletedDate, будет достаточной для SQL, чтобы использовать этот индекс. Однако добавление DeletedDate к существующим индексам, используемое вместе с другими более избирательными столбцами, должно дать некоторое преимущество, если оно увеличивает общую селективность индекса.

Как говорит JNK, DeletedDate будет мало полезен при покрытии индексов, если вы не используете его в предложении SELECT.

Учитывая, что для индексов уже больше места, чем для данных, вы также можете посмотреть, есть ли избыточность в существующих 15 индексах NC.