Discussion :

[olibara]

Bonjour

J'ai survolé le tuto de SQL Pro

http://sqlpro.developpez.com/cours/quoi-indexer/

Je pense qu'il reponds a une question que je me suis souvant posée

Si dans une table j'ai un champ Numero et en champ Date

Si je crée un index Numero, Date, est it utile d'avoir aussi un index Numero

Le tutorial dit assez clairement : NON ce n'est pas nécessaire
Ai-je bien compris ?
Il y aurait-il une exception a cette regle ?

Merci de votre savoir

[fsmrel]

Bonsoir olibara,


Si pour la table T vous avez créé un index X1 ayant pour clé le couple {Numero, Date}, un index supplémentaire X2 ayant pour clé {Numero} est parfaitement inutile. Cependant, si par exemple la clé primaire de la table T est {Numero}, les SGBD feignants vous forceront à créer X2, même si la table ne comporte qu’une ou deux lignes.

[olibara]

Merci fsmrel

Mais MS Qql cree automatiquement un index sur la Pk ...?
Non ?

[hmira]

Merci fsmrel

Mais MS Qql cree automatiquement un index sur la Pk ...?
Non ?

Oui, il y a toujours un index physique rattaché à la clé primaire. Il faut cependant distinguer si l’index est organisé en cluster ou non.

Une clé primaire est d’abord une contrainte. Pour gérer la contrainte de clé primaire, SQL Server créé automatiquement un index physique associé. De même qu’une contrainte d’unicité (CONSTRAINT … UNIQUE) est gérée physiquement par un index unique.
Lorsque la clé primaire (PRIMARY KEY) est créée avec la clause CLUSTERED, l’index associé à la clé primaire est un index cluster et pour une table donnée il ne peut y avoir au plus qu'un seul index organisé en cluster et auquel cas la table et l’index se confondent et ne font plus qu’un.

A+

[hmira]

Pour revenir à question initialement posée. Personnellement je serais entièrement d’accord avec et SQLPro et fsmrel a propos de l’affirmation selon laquelle :

Si l'index IXn est composée des colonnes C1, C2, ..Cn alors
Il est "généralement" inutile de créer un index IXp constitué des colonnes C1, C2,…Cp (où p < n et où l’ordre des colonnes et les clauses ASC ou DESC de chacune des colonnes Ci (i varie de 1 à p) de l'index IXp et de l'index IXn , sont exactement identiques)
FinSi

PS : je me suis permis de rajouter le mot "généralement" et tout est dans le mot "généralement" !

Si on ôte le mot "généralement", la démonstration formelle de l’assertion ci-dessus n’est chose aisée. En effet, pour cela, il faudra revenir à la structure interne des Indexes B-Tree et la façon (où l’algorithme interne) utilisé par l’optimiseur de requête pour déterminer le plan d’exécution le plus efficace pour extraire les données demandées, etc.. Et, personnellement, si on ôte le mot "généralement", j’aurais même tendance à conjecturer qu’elle serait fausse !

En effet, on peut facilement trouver des situations, certe très rares où l’utilisation de l’index IXp s’avère plus optimale. Ce serait le cas notamment si les colonnes Cp+1 … Cn sont très longues (exemple des CHAR(8000) ! oui cela peut surprendre, mais on peut imaginer le pire) et où la requête SELECT porte uniquement sur les colonnes Ci où i <= p (c.à.d cas où la lecture de l’index suffit, et il ne sera pas nécessaire d’aller lire d’autres données dans la table).
Exemple :

Code SQL :

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

1
2
3
4
5
SELECT C1, .. Cp
FROM Matable 
WHERE C1 = .. 
AND   C2 = .. 
AND   Cp = ..

Dans ce contexte, il n’est pas exclu que l'optimiseur privilégie l’index IXp au lieu de l'index IXn

Conclusion :
Il s’agit donc plus d’une règle de bonne pratique que d’un "théorème" démontrable et vérifiable quel que soit le contexte.

A+

[SQLpro]

Pour compléter ce qui vient d'être dit, il est possible de savoir quels sont les index inclus par la requête que j'ai posté ici :
http://blog.developpez.com/sqlpro/p9...s_index_anorma

A +