Warum manchmal Table Scan ist schneller als Index-Scan?

Ich habe eine Tabelle erstellt, um die Anzahl der logischen Blöcke zu testing, die gelesen werden, und der Ausführungsplan, der von dem Abfrageoptimierer ausgewählt wurde, wobei die Abfragen verglichen werden, wenn diese Tabelle Index hat und wann sie nicht hat.

der prüftisch ist

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) ) 

Wenn ich von diesen Fragen abhänge:

 select * from scan select id from scan 

Ich habe 88 und 58 logische Lesungen und einen Tabellen-Scan-Algorithmus

Dann ändere ich den Tisch, der die pk-Einschränkung und seine gruppierte ID setzt

 alter table scan add constraint fk_id primary key (id) 

dann laufen die gleichen fragen:

 select * from scan select id from scan 

und ich bekam 90 und 60 Scan-Lesevorgänge und den Index-Scan-Algorithmus

Die Frage ist: Wenn der Abfrage-Optimierer den besten path zum Ausführen der Abfrage wählt, warum wählt man den Index-Scan, wenn der Tabellen-Scan weniger Block lesen kann?

Wenn Sie die Primärschlüssel-Einschränkung erstellt haben, wurde sie standardmäßig gruppiert. Dies bedeutet, dass der Haufen, den Sie zuvor von diesem Schlüssel bestellt hatten ( id , in Ihrem Fall).

data in Tabellen können auf zwei Arten gespeichert werden: entweder Haufen oder gruppierte Indizes. Wenn das letztere entsteht, ist das ehemalige weg. So ist es unmöglich für SQL server, Tabellen-Scan auf Index durchzuführen – es kann nur ein Index-Scan (gruppierte Index-Scan, btw – das ist wichtig).

Ich weiß, es mag verwirrend klingen, aber versuchen, einige Grundlagen auf gruppierten Indizes zu lesen – es könnte helfen.