Perché una ricerca indice diventa più costosa di una scansione indice

Question

Ho una domanda di base su Scansione indice/Ricerca. La scansione indice è efficace quando è presente un numero elevato di righe da recuperare. Questo è il costo della scansione dell'indice inversamente proporzionale al numero di righe restituite. Questo è meno il numero di righe più costose della query diventa come deve scansionare tutte le pagine che si traduce in più IO.

Ho cercato il motivo per cui le ricerche diventano più costose delle scansioni ma non sono in grado di ottenere il motivo per cui la ricerca diventa costosa.

Ciò che mi confonde è con Ricerca indice. Perché la ricerca indice diventa costosa con più numero di righe restituite. La ricerca dell'indice sarà sempre più veloce ed efficiente delle scansioni poiché tocca direttamente le pagine che contengono le righe. Quindi, anche con un numero elevato di righe restituite, la ricerca dell'indice dovrebbe sempre essere efficace rispetto alla scansione dell'indice. Ma questo non succede. Voglio sapere esattamente perché a un certo punto la ricerca diventa costosa.

select id,name,col1,col2 
from TableA -- Will result in index scan. Table has 10000 rows with clustered index on ID column. Query has covering index. 

select id,name,col1,col2 
where ID between 1 and 10 
from TableA -- Optimizer Will use index Seek. 

Ora, perché fa la domanda sotto diventa costoso quando Index Seek è costretto su -

select id,name,col1,col2 
from TableA with (forceseek) 

Answer 1

Il motivo per cui Clustered Index Seek è costoso di scansione Indice è perché indice di ricerca inizia a leggere il diritto albero B dai nodi radice ai nodi foglia. Ciò comporta la lettura dell'indice e delle pagine all'interno dei nodi Leaf. Di qui i risultati in più IO. Quindi, quando la selettività è meno ottimizzata, sceglie la scansione indice invece della ricerca indice. La ricerca è migliore solo quando i record restituiti non superano il 2-3%.