Cela dépend de la façon dont vous recherchez.
Si vous recherchez comme ceci :
/* Given a value from table1, find all related values from table2 */
SELECT *
FROM table1 t1
JOIN table_table tt ON (tt.table_1 = t1.id)
JOIN table2 t2 ON (t2.id = tt.table_2)
WHERE t1.id = @id
alors vous avez besoin de :
ALTER TABLE table_table ADD CONSTRAINT pk_table1_table2 (table_1, table_2)
Dans ce cas, table1 sera en tête dans NESTED LOOPS et votre index ne sera utilisable que lorsque table1 est indexé en premier.
Si vous recherchez comme ceci :
/* Given a value from table2, find all related values from table1 */
SELECT *
FROM table2 t2
JOIN table_table tt ON (tt.table_2 = t2.id)
JOIN table1 t1 ON (t1.id = tt.table_1)
WHERE t2.id = @id
alors vous avez besoin de :
ALTER TABLE table_table ADD CONSTRAINT pk_table1_table2 (table_2, table_1)
pour les raisons ci-dessus.
Vous n'avez pas besoin d'indices indépendants ici. Un index composite peut être utilisé partout où un index simple sur la première colonne peut être utilisé. Si vous utilisez des index indépendants, vous ne pourrez pas rechercher efficacement les deux valeurs :
/* Check if relationship exists between two given values */
SELECT 1
FROM table_table
WHERE table_1 = @id1
AND table_2 = @id2
Pour une requête comme celle-ci, vous aurez besoin d'au moins un index sur les deux colonnes.
Il n'est jamais mauvais d'avoir un index supplémentaire pour le second champ :
ALTER TABLE table_table ADD CONSTRAINT pk_table1_table2 PRIMARY KEY (table_1, table_2)
CREATE INDEX ix_table2 ON table_table (table_2)
La clé primaire sera utilisée pour les recherches on both values et pour les recherches basées sur la valeur de table_1 , un index supplémentaire sera utilisé pour les recherches basées sur la valeur de table_2 .
