Indexez ce qui semble le plus logique (qui devrait, espérons-le, être évident, par exemple, une colonne d'ID client dans la table CUSTOMERS).
Exécutez ensuite votre application et collectez régulièrement des statistiques pour voir comment la base de données fonctionne. RUNSTATS sur DB2 en est un exemple, j'espère que MySQL dispose d'un outil similaire.
Lorsque vous trouvez que certaines requêtes souvent exécutées effectuent des analyses de table complètes (ou prennent trop de temps pour d'autres raisons), alors, et alors seulement , si vous ajoutez d'autres index. Il ne sert à rien d'optimiser une requête exécutée une fois par mois à minuit afin qu'elle puisse se terminer à 12h05 au lieu de 12h07. Cependant, c'est une énorme amélioration de réduire une requête destinée aux clients de 5 secondes à 2 secondes (c'est encore trop lent, les requêtes destinées aux clients devraient être inférieures à une seconde si possible).
Plus d'index ont tendance à ralentir les insertions et à accélérer les requêtes. C'est donc toujours un exercice d'équilibre. C'est pourquoi vous n'ajoutez des index qu'en réponse spécifique à un problème. Tout le reste est une optimisation prématurée et doit être évité.
De plus, revoyez périodiquement les index que vous avez déjà pour voir s'ils sont toujours nécessaires. Il se peut que les requêtes qui vous ont amené à ajouter ces index ne soient plus exécutées assez souvent pour le justifier.
Pour être honnête, je ne pense pas que l'indexation de trois colonnes sur une table vous fera souffrir à moins que vous ne prévoyiez de stocker un très grand nombre de lignes :-) - l'indexation est assez efficace.
Après votre modification qui indique :
Ma réponse est que 200 enregistrements par jour est une valeur extrêmement petite pour une base de données, vous n'aurez certainement pas à vous soucier de ces trois index.
Juste cette semaine, j'ai importé une journée de transactions dans l'une de nos tables de base de données au travail et elle contenait 2,1 millions d'enregistrements (nous obtenons au moins une transaction par seconde sur toute la journée à partir de 25 machines distinctes). Et il dispose de quatre clés composites distinctes, ce qui est un peu plus intensif que vos trois clés individuelles.
Maintenant accordé, c'est sur une base de données DB2 mais je ne peux pas imaginer qu'IBM soit si bien mieux que les gens de MySQL que MySQL ne peut gérer que moins de 0,01 % de la charge DB2.
