Почему иногда сканирование таблицы происходит быстрее, чем сканирование индекса?

Question

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

тест стол

create table scan 
( 
     id int identity(1, 1), 
     a varchar(10), 
     b varchar(10), 
     c varchar(10), 
     d varchar(10), 
     e varchar(10), 
     f varchar(10) 
) 

Когда я бегу из этих запросов:

select * from scan 
select id from scan 

я получил 88 и 58 логических операций чтения и алгоритм сканирования таблицы

Тогда я изменить таблица, в которой установлено ограничение pk и его кластерный идентификатор

alter table scan 
add constraint fk_id primary key (id) 

затем запустить те же запросы:

select * from scan 
select id from scan 

, и я получил 90 и 60 сканирования читает и алгоритм сканирования индекса

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

Answer 1

Когда вы создали ограничение первичного ключа, оно было снесено кластером по умолчанию. Это означает, что куча, которую вы ранее предварительно заказали по этому ключу (id, в вашем случае).

Данные в таблицах могут храниться одним из двух способов: кучи или кластерные индексы. Когда последний создается, первый исчез. Таким образом, SQL Server не может выполнять сканирование таблицы по индексу - это может быть только сканирование индекса (кластерное сканирование индекса, btw - это важно).

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