Pour vraiment donner une réponse, il serait utile de voir si vous avez déjà des index existants, mais...
Tout cela suppose que la table 't' existe et que vous devez ajouter un index et que vous n'avez actuellement qu'un seul index sur votre clé primaire ou aucun index du tout.
Un index de couverture pour la requête donnera les meilleures performances pour vos besoins, mais avec n'importe quel index, vous sacrifiez une certaine vitesse d'insertion. L'importance de ce sacrifice dépend du profil de votre application. Si vous lisez principalement à partir du tableau, cela n'aura pas beaucoup d'importance. Si vous n'avez que quelques index, même une charge d'écriture modérée n'aura pas d'importance. L'espace de stockage limité pour vos tables peut également entrer en jeu... Vous devez faire l'évaluation finale du compromis et s'il est perceptible. La bonne chose est que c'est un succès assez constant. En règle générale, l'ajout d'un index ne ralentit pas vos insertions de manière exponentielle, mais uniquement de manière linéaire.
Quoi qu'il en soit, voici vos options pour obtenir les meilleures performances :
- Si c3 est votre clé primaire pour la table t, vous ne pouvez rien faire de mieux dans la requête pour la rendre plus rapide avec un index.
-
En supposant que c1 est votre clé primaire t :
ALTER TABLE t ADD INDEX covering_index (c3,c2); -
Si c1 n'est pas votre pk (et c2 non plus), utilisez ceci :
ALTER TABLE t ADD INDEX covering_index (c3,c2,c1); -
Si c2 est votre PK, utilisez ceci :
ALTER TABLE t ADD INDEX covering_index (c3,c1); -
Si l'espace sur le disque ou la vitesse d'insertion est un problème, vous pouvez choisir de faire un index de points. Vous sacrifierez certaines performances, mais si vous utilisez beaucoup d'inserts, cela pourrait être la bonne option :
ALTER TABLE t ADD INDEX a_point_index (c3);
