185
6.4 Statistiques
SELECT COUNT(*)
FROM Production.TransactionHistory
WHERE ProductId = 800
Si le ratio entre le nombre de lignes qui répond au critère recherché et le nombre
total de ligne est faible, SQL Server va choisir d’utiliser l’index. Si par contre il est
important, et qu’une bonne partie des lignes de la table doit être retournée par la
requête, SQL Server va certainement faire le choix de parcourir la table plutôt que
d’utiliser l’index, parce qu’il sera moins coûteux de procéder de cette façon que de
résoudre ligne par ligne les adresses de pointeurs contenues dans le dernier niveau de
l’index.
6.4.1 Statistiques sur les index
Dans le cas qui nous occupe, ProductId = 800 correspond à 416 lignes / 133 443.
Voyons le plan d’exécution estimé en XML :
DBCC FREEPROCCACHE
GO
SET SHOWPLAN_XML ON
GO
SELECT *
FROM Production.TransactionHistory
WHERE ProductId = 800
GO
SET SHOWPLAN_XML OFF
GO
Un extrait de ce plan :
LogicalOp="Clustered Index Scan" EstimateRows="418"
EstimateIO="0.586088" EstimateCPU="0.124944" AvgRowSize="54"
EstimatedTotalSubtreeCost="0.711032"
Parallel="0" EstimateRebinds="0"
EstimateRewinds="0">
Nous voyons que l’optimiseur choisit de parcourir la table (donc ici un scan de
l’index clustered, puisque le dernier niveau de l’index clustered correspond aux données de la table) au lieu d’utiliser l’index. Nous voyons aussi dans l’attribut EstimateRows que les statistiques permettent à l’optimiseur d’avoir une idée assez précise du
nombre de lignes correspondant à la clause WHERE.
Essayons maintenant d’indiquer un nombre plus petit de lignes à retourner :
SELECT ProductId, COUNT(*)
FROM Production.TransactionHistory
GROUP BY ProductId;
Nous voyons par exemple que le ProductId 760 ne se retrouve que six fois dans la
table. Essayons avec cela :
DBCC FREEPROCCACHE
GO