SQL запрос не использует доступный индекс (SQL Server 2008)

Question

я следующую таблицу в SQL Server 2008:

Session 
(
sessionid varchar(10) 
startdate dateteime 
enddate dateteime 
--rest of the fields go here 
) 

Я следующие два некластеризованные индексы созданы:

Inddex1: SessionID,startdate,enddate 
Inddex2: startdate,enddate 

У меня есть следующий запрос

select * 
from session 
where startdate>=@date1 and enddate <=@date2 

при выполнении этого запроса оба эти идекса не используются. В плане запроса отображается только просмотр таблицы.

Теперь я попытался удалить index1 и выполнить тот же SP Still index2 не используется.

Любые подсказки о том, как заставить SP использовать index2? (Нет принудительного использования индекса, пожалуйста.)

Answer 1

Возможно, у вас есть кластерный индекс в столбце SessionID? В этом случае ваши индексы в основном идентичны, так как любой некластеризованный индекс будет неявно включать кластеризованный ключ.

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

Answer 2

Сводный индекс не будет использоваться, поскольку он не может использоваться для оптимизации этого запроса. Вы должны создать отдельный индекс для каждого столбца.

Answer 3

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

Я не уверен, что получаю смысл этих двух составных индексов. Разве вы не были бы лучше с индивидуальным индексом на даты?

Answer 4

Вы говорите, что процессор запросов не использует один из ваших индексов, но вы не говорите нам, что это is. Я предположим, что сканирование таблицы ...?

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

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

Рассмотрите возможность изменения запроса и/или индекса, чтобы вы только выбирали поля, которые полностью покрыты индексом. Тогда я ожидаю, что вы увидите использование индекса. Но это не всегда правильно - создание огромного индекса для редко используемого запроса может быть неправильным.

Answer 5

Любой индекс с «стартовой» в качестве первого столбца может помочь с поиском startdate> = @ date1. Любой индекс с «enddate» в качестве первого столбца может помочь с поиском «enddate < = @ date2». Но нет индекса, который может помочь с обоими.

И если предположить, что почти нет enddates с одинаковой начальной точкой, индекс on (startdate, enddate) не более полезен, чем индекс на (startdate).

Таким образом, сканирование таблицы кажется надежным выбором для Sql Server.

Даже если вы ищете startdate> = @ date1, все же имеет смысл делать сканирование таблицы. Сканирование индекса даст вам много ссылок на таблицу, которые вам придется решать, что не стоит для большого количества данных.

один запрос, который должен использовать индекс:

select * from session where startdate = @date1 

Во всяком случае, если вы думаете, что вы знаете лучше, чем оптимизатор, вы можете принудительно использовать индекс, как:

select * 
from session with (index indexname) 
where startdate>=@date1 and enddate <=@date2