Pourquoi SQL server n'utilise pas le bon index

Bonjour,

j'aimerais savoir pourquoi SQL Server n'utilise pas l'index sur la colonne

Code:

---

1 2 3

select * from fact_prm where prm_d_crt > '20070101'

---

J'ai un index sur la colonne prm_d_crt mais je ne sais pour quelle raison lorsque je demande d'afficher le plan d'execution il affiche le Clustered Index Scan

alors que la requête

Code:

---

1 2 3

select * from fact_prm where prm_d_crt = '20070101'

---

utilise bien l'index sur la colonne prm_d_crt.

voici le script de création d'index

Code:

---

1 2 3 4 5 6

/****** Object: Index [IX_D_CREA] Script Date: 02/13/2009 16:26:35 ******/ CREATE NONCLUSTERED INDEX [IX_D_CREA] ON [dbo].[FACT_PRM] ( [PRM_D_CRT] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

---

Bonjour,

Une des premières raison est parce que vous utilisez SELECT *.
Même si vous avez besoin de toutes les colonnes, n'utilisez jamais SELECT *.

Ensuite combien de lignes compte votre table, et parmi celles-ci combien correspondent au critère de la clause WHERE ?
Si beaucoup de lignes répondent à cette clause, alors le moteur va préférer parcourir toute la table que de chercher dans l'index, s'il estime que cela est plus rapide / moins gourmand en ressources.

Enfin votre index n'est pas couvrant, c'est-à-dire que les colonnes impliquées dans votre requête ne sont pas la clé de l'index.
Je ne peux pas vous guider parce que vous avez utilisé un SELECT *.

Si vous êtes en 2005, n'oubliez pas la clause INCLUDE de l'ordre CREATE INDEX ;)

@++ ;)

Pour savoir si SQL Server à raison de ne pas utiliser cet index il suffit de lui faire exécuter la requête en lui forçant à utiliser cet index puis naturellement et en regardant le nombre d'IO effectué dans chaque cas.
Ce n'est pas parce que vous mettez un index que ce sera automatiquement choisit. Avant d'exécuter, SQL Server analyse toutes les combinaisons, les évalues et choisit la meilleure.

En supposante que votre index s'apelle X_FAC_PRM

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

-- affichage des stats de lectures SET STATISTICS IO ON; GO -- forçage de l'index SELECT * FROM fact_prm WITH( INDEX (X_FAC_PRM)) WHERE prm_d_crt > '20070101'; GO -- choix SQL SELECT * FROM fact_prm WHERE prm_d_crt > '20070101'; GO

---

Regardez dans l'onglet des messages et concluez par vous même !

A +

Citation:

---

Envoyé par elsuket

Bonjour,

Une des premières raison est parce que vous utilisez SELECT *.
Même si vous avez besoin de toutes les colonnes, n'utilisez jamais SELECT *.

Ensuite combien de lignes compte votre table, et parmi celles-ci combien correspondent au critère de la clause WHERE ?

---

Ma table a 54 colonnes, dans la clause where il y a 1 seule colonne. Ce qui me semblait logique c'est qu'en faisant un critère sur la date de création "prm_d_crt" > 2007 ça élimine un bon nombre de résultats.

Ma table possède 2340467 lignes. Ma requête me retourne 500000 lignes environs. Donc pourquoi parcourir tous les 2 millions de records quant on peut en éliminer les 3/4? :cfou:

Citation:

---

Enfin votre index n'est pas couvrant, c'est-à-dire que les colonnes impliquées dans votre requête ne sont pas la clé de l'index.
Je ne peux pas vous guider parce que vous avez utilisé un SELECT *.

---

Alors pourquoi lorsque je demande WHERE d_crt = '20070101' SQL server passe bien par cet index?

Citation:

---

Pour savoir si SQL Server à raison de ne pas utiliser cet index il suffit de lui faire exécuter la requête en lui forçant à utiliser cet index puis naturellement et en regardant le nombre d'IO effectué dans chaque cas.
Ce n'est pas parce que vous mettez un index que ce sera automatiquement choisit. Avant d'exécuter, SQL Server analyse toutes les combinaisons, les évalues et choisit la meilleure.

---

Je l'ai fait voilà ce que ce me retourne, mais ça veut dire quoi?



(522639 row(s) affected)
Table 'FACT_PRM'. Scan count 1, logical reads 2126274, physical reads 10908, read-ahead reads 1920, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(522639 row(s) affected)
Table 'FACT_PRM'. Scan count 1, logical reads 107961, physical reads 4, read-ahead reads 107959, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.