D'un point de vue purement logique, si j'ai un index ixA : (a) et un index ixB (a, b, c), en prenant en compte que la colonne "a" est la seule de l'index ixA et est la première de l'index ixB, je pense que l'index ixA est inutile.
 
En effet, si j'ai une requête dont la clause WHERE ne porte que sur "a", à priori, que j'utilise le premier noeud de ixB ou l'index ixA me semble totalement équivalent.
 
Seulement, je n'ai jamais pu le lire noir sur blanc dans une documentation, et les optitimisations liées aux index sont trop "aléatoires" pour pouvoir être mesurées avec précision sur une base de test (les index ne sont pas actifs immédiatement, une fois que le plan est connu et les résultats en cache, le vitesse ne dépend plus de la structure de la base, etc.)
 
Alors... Est-ce que quelqu'un pourrait confirmer ce point ?
 
En effet, j'ai, dans une base SQL Server, environ 20 index. C'est une table qui comporte plusieurs millions de lignes, et il est dont indispensable que les index soient les plus performants possibles.
 
Cependant, on fait des requêtes dans cette base de données via des bases Access, qui passent par des tables liées. Hors, pour une raison inconnue, si on a trop d'index, ça ne fonctionne pas !
 
Vu que certains index tels que ixA et ixB semblent faire doublon, je compte les fusionner, afin de créer de nouveaux index qui sont nécessaires à de nouveaux développements.
 
Merci d'éclairer ma lanterne !

Ah ben voilà !
 

(Issu de la doc officiel de SQL Server 2000)
 
Donc mon ixA peut être supprimé, il n'apporte rien (ou presque) par rapport à ixB !
 
Chouette ! Ca fait déjà 4 index de moins dans la table !

et pourquoi tu fais pas un petit test de perfs ?
 
Ca m'étonnerait pas que l'index sur A seul soit un poil plus rapide, juste à cause de la taille de l'index à gérer qui est plus petite mais ça doit pas se jouer à grand chose.

Ben parceque comme je l'ai dit, y'a un truc qui coince avec les index :
-> Fait une requête maxi complète qui tape sur des millions de lignes. A la première execution, ça dure 20 minutes. A la seconde execution, si tu la fait dans la foulée, il a encore tout en cache (plan d'éxécution et données) et pof, ça dure 20 millisecondes.
 
Idem, tu crées un index, tu refais une requête lente, qui devrait taper dedans. Ca ramme toujours autant.
Tu fais un update statistics, ça change rien.
Le lendemain, ta requête est instantannée.
 
Le souci des index, c'est que ça se fait en tâche de fond. Du coup, un même bench peut donner des résultats très différents à différents moment, même sans mise à jours de la structure de la table (un grand nombre de modifications dans la base peuvent suffir à pourrir un index pendant plusieurs heures)

Sinon, c'est sûr que ixA est très certainement un peu plus rapide. Mais ce qui m'importe, c'est que ixB soit tout de même efficace. En effet, les autre index à ajouter sont carrément vitaux pour le fonctionnement de la nouvelle appli (avec ou sans, ça passe de 20 minutes à 13 secondes, donc si les autres requêtes passent de 2 à 3 secondes, y'a moindre mal, d'autant plus que la mise en prod de la nouvelle appli s'accompagne de la mise en place d'une batterie de nouveaux serveurs, donc on devrait rien perdre en perfs, même si les index sont un peu moins bons )

Je pense pas qu'il y ait une diminution notable des performances en utilisant la première colonne d'un index plutôt qu'un index indépendant.
Et puis tu devrais y gagner un petit peu lors des insertions