Discussion :

[Invité]

Bonjour,

J'ai une table d'asso qui ressemble en gros à çà :
ID : PK
REFA : clé étrangère vers une table A
REFB : clé étrangère vers une table B

Ma table a environnement 1 million d'enregistrements.

Il y a un index non unique sur la colonne REFA.
et un autre non unique sur la colonne REFB.

J'ai aussi une requête qui fait çà :
select REFB from MATABLE where REFA = ?

Je viens de remarquer la chose suivante. J'ai crée un index UNIQUE
sur les colonnes (REFA,REFB) et depuis, la requête est beaucoup plus
performante.

Donc j'en déduis que sur ce genre de table, il vaut mieux 2 index
uniques (REFA,REFB) et (REFB,REFA) que un index non unique sur chaque
colonne. Ca va augmenter la taille de mes index mais bon...

Si vous pouvez me renseigner là dessus.... merci

[mnitu]

J’aurais crée la table avec seulement les colonnes REFA, REFB et une contrainte de type clé primaire et donc automatiquement un index unique REFA, REFB. Bon il faut analyser les requêtes pour décider finalement l’ordre des colonnes dans l’index.

Dans votre cas il est normal que la requête soit plus rapide parce que dans le premier cas il y a un accès à l’index suivi d’un accès à la table; dans le deuxième cas l’index suffit pour répondre à l’interrogation.

Il n’est ni possible ni envisageable de créer les deux indexes comme vous le proposez (un REFA,REFB et un autre REFB, REFA). Dans le pire des cases vous pouvez créer un index sur REFA, REFB et un autre sur REFB seule.

[Invité]

Ah oui, c'est çà que j'avais zappé... il n'y a plus besoin d'aller voir
dans la table vu que toutes les données sont dans l'index.

Merci.