191
6.4 Statistiques
au.type_desc AS allocation_type,
au.data_pages, partition_number
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
JOIN sys.objects AS o ON p.object_id = o.object_id
LEFT JOIN sys.indexes AS i ON p.index_id = i.index_id
AND i.object_id = p.object_id
WHERE o.name = N'TransactionHistory'
ORDER BY o.name, p.index_id
Tableau 6.9 — Allocation des index
Nous pouvons donc assumer qu’un scan de la table (donc de l’index clustered)
coûtera la lecture de 788 pages, donc 788 reads. Cela représente bien plus que 418
pages. Pourquoi choisir un scan ?
Analysons ce qui se passe réellement lorsque nous utilisons un plan ou un autre.
Nous pouvons le découvrir en forçant l’optimiseur à utiliser l’index en ajoutant un
indicateur de table dans la requête (nous verrons les indicateurs de table dans la
section 8.2.1) :
SET STATISTICS IO ON
GO
SELECT *
FROM Production.TransactionHistory
WITH (INDEX = IX_TransactionHistory_ProductID)
WHERE ProductId = 800
Voici les résultats de pages lues (reçues grâce à SET STATISTICS IO ON), et le plan
d’exécution utilisé :
Table 'TransactionHistory'.
Scan count 1, logical reads 1979, physical reads 3,
read-ahead reads 744,
lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Relançons ensuite la requête en laissant SQL Server choisir son plan :
SELECT *
FROM Production.TransactionHistory
WHERE ProductId = 800
Résultat :
Table 'TransactionHistory'.
index_name
allocation_type
data_pages
PK_TransactionHistory_TransactionID
IN_ROW_DATA
788
IX_TransactionHistory_ProductID
IN_ROW_DATA
155
IX_TransactionHistory_ReferenceOrderID
_ReferenceOrderLineID
IN_ROW_DATA
211