Discussion :

[fred_04510]

Bonjour,
J'ai la requête suivante de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select * 
from TABLE 
where date >= '01/01/2008' 
and date <'01/01/2009'

1) Le champs date est de type datetime.
2) Cette requête requete renvoie 500 000 lignes sur 1 000 000.
3) Il existe un unique clustered index TABLE_PK sur cette table (sur un autre champs que date).
4) Il existe un index IX_TABLE_date non clustered sur le champs date.
5) Les statistiques sont à jour.

Le plan d'exécution de la requête révèle que optimiseur a fait un clustered Index scan sur l'index TABLE_PK. Pourquoi n'utilise t'il pas l'index IX_TABLE_date ?

Merci d'avance pour votre aide.

[elsuket]

Bonjour,

2 raisons à cela :

- parce que l'optimiseur a estimé qu'il lui coûterait moins cher de parcourir toute la table (vous retournez un nombre important de lignes par rapport au nombre total de lignes de la table)

- parce que vous avez mis SELECT *, donc aucun index ne couvre la requête, donc l'optimiseur choisit de parcourir la table.

N'utilisez jamais * dans une requête de production, sauf pour le prédicat EXISTS, ou la fonction d'aggrégat COUNT, qui sont optimisées pour

@++

[fred_04510]

Merci, j'ai appris un truc.
C'est spécifique à sqlserver ?

[elsuket]

Vous voulez dire pour "*" ? Non, je ne pense pas

@++

[fred_04510]

Pourriez vous me donner une source officielle indiquant qu'il ne faut pas utiliser select * ?
Je n'arrive pas à trouver ça sur le net.

Merci encore pour votre aide.

[elsuket]

Malheureusement je ne peux pas, mais à votre avis que fait le moteur de base de données quand vous spécifiez SELECT * ?

Il va chercher dans les tables système le nom des colonnes de la table pour bâtir ensuite le plan de requête optimal.
Vous créez donc ainsi un peu plus de surcharge au serveur ...
Je vous laisse imaginer ce que cela fait quand vous spécifiez des jointures ...

@++