SQL Server не использует индекс, сравнивающий дату и время с ненулевым

Question

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

выбрать * из таблицы, где столбец даты не равен нулю <- не использует индекс и работает очень медленно. </p>

Но если я уберу не, вот так: выберите * из таблицы, где datecolum равен нулю <- использует индекс и работает очень быстро. </p>

Существует гораздо больше не нулей, чем нулей.

Я что-то забыл? Могу ли я использовать фильтрованный индекс здесь?

Заранее спасибо.

Answer 1

Это нормально.Он не будет использовать индекс, если предикат не будет достаточно избирательным, чтобы его оправдать.

Похоже, что подавляющее большинство записей не NULL, поэтому вместо их поиска по некластерному индексу необходимо выполнить множествопоиск закладок и случайный ввод / вывод для извлечения остальных столбцов, чтобы вернуть, это быстрее и эффективнее просто сканировать весь кластеризованный индекс.

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

SET STATISTICS IO ON

SELECT * FROM 
YourTable WITH (FORCESEEK) 
WHERE YourCol IS NOT NULL

Answer 2

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

SQLServer (и любые другие реляционные базы данных дляэто имеет значение) использует статистику, чтобы определить, какой план запроса он будет использовать.Статистика, вероятно, говорит базе данных, что есть много строк с ненулевыми датами.Поэтому, возможно, SQLServer считает, что использование индекса не стоит того, и FULL TABLE SCAN - лучший план для этого конкретного запроса с условием NOT NULL .

Я хочу упомянуть две вещи:

1. Запрос с использованием не всегда быстрее, чем запрос без использования one.
2. Вы можете поместить INDEX HINT на ваш запрос, но я обычно нахожусь в том, что стреляю себе в ногу, выполняя такую ​​ оптимизацию .