Salut,
Eh bien non, l'index n'est pas forcément utilisé. SQL Server maintient des statistiques de distribution des données dans l'index (DBCC SHOW_STATISTICS ( table , index )). Il sait donc à peu près quel est sa sélectivité (le nombre de valeurs différentes dans l'index).
Si l'index est peu sélectif (= beaucoup de doublons), SQL server peut choisir de ne pas l'utiliser, parce que le coût de parcours de l'index pour chaque enregistrement à retourner est estimé plus élevé qu'un scan de la table.
Si dans l'exemple de sohm:
select * from table where col1 = @col1 and col2 = @col2
il y a un index non ordonné (col1, col2), et col1 est un bit qui comporte 50% de 1 et 50% de 0, ou simplement un int qui contient la valeur 10 sur peut-être 20% ou 30% des enregistrements, SQL Server peut très bien décider de se passer de l'index. Il aura raison, ce serait plus coûteux de l'utiliser.
Potentiellement, il pourrait aussi décider de ne pas utiliser l'index s'il sait qu'il doit retourner beaucoup d'enregistrements, et que, comme on le voit ici, il y a un SELECT * ou un SELECT de colonnes qui ne sont pas dans l'index, parce que le coût des bookmarks lookups ou des parcours de l'index ordonné sera estimé plus important que le scan. Mais c'est probablement plus rare.
Dans ces cas, inutile de créer un index qui ralentira les opérations DML (insert, update).
Il y a sans doute d'autres cas, par exemple s'il y a deux index, un sur col1 et l'autre sur col2, l'optimiseur pourrait choisir de n'en utiliser qu'un. C'est toujours une bonne idée de s'assurer que l'index est utilisé.
Partager