Je suis content d’avoir trouvé ce site qui met en avant certain points obscures pour moi sur Mysql.

Jusque là je ne m’étais jamais trop soucié de l’optimisation. Mes études m’ont appris beaucoup de choses sur les bases de données mais ce n’était jamais poussé sur l’optimisation.
J’ai toujours travaillé sur des tables petites (des milliers d’enregistrements) Mais là je suis dans un cas ou j’utilise des tables contenant des données par millions… Et là une requête que l’on utilise depuis toujours, on se rend compte qu’elle est trop gourmande en ressource et juste en la reformulant différemment on gagne énormément.

Mais là où j’ai le plus gagné, c’est vraiment sur l’utilisation des index. C’est impressionnant.

Je vais tester tes indications. Mais j’ai déjà appris pas mal par le biais de ce site, merci.

Concernant ma remarque il faut bien noter que lorsque je dis l’ordre il s’agit ici d’un index composé à 3 champs et que seul le 1er et le 3eme champs sont utilisés dans mon exemple, empêchant MySQL de tirer parti de l’index composé pour le 3eme champ.

A propos de ta requête je te conseille d’executer un SHOW INDEX FROM… afin d’observer les cardinalités.

Au cas où celles-ci soient nulles, et si ta table est de taille moyenne ou InnoDB (qui fonctionne par « plongées » statistiques aléatoires pour sortir une approximation : moins fiable mais bcp plus rapide que MyISAM -> tres long sur grosse table), tu peux tenter un ANALYZE TABLE … pour maj ces statistiques.

MySQL a peut-être une bonne raison de se dire que c’est le tri sur idaction qui est le plus déterminant, auquel cas mysql préfère utiliser l’index le plus petit en taille (key_len dans le EXPLAIN) ou le plus rapide à parcourir.

Tu peux aussi simuler l’absence de cet index à part posé sur idaction et observer ce que ca donne :
EXPLAIN SELECT … FROM … ignore index (idx_idaction) WHERE…

Tu verras ainsi si sans cet index à part MySQL utilise bien ton index composé.

J’ai enfin trouvé des réponses sur les index! J’y vois plus clair maintenant, merci.

Mais j’ai une question, il est dit dans l’article:

« En revanche, si l’ordre de vos champs ne respecte pas l’ordre de séquence de votre index, comme ici :

SELECT … FROM City WHERE Name = … AND Population = ..

Cette requête ne bénéficiera pas complètement de l’index multiple précedemment crée, cela dit l’optimiseur tirera sûrement parti de cet index pour la colonne Name, mais pas pour le second critère de recherche. »

Or j’ai une requête qui a pour condition:
SELECT … FROM .. WHERE idsite =2 AND date = ‘2010-01-03′ GROUP BY action

j’ai donc créé un index sur: idsite, date, action (dans cet ordre)
seulement j’ai un autre index sur action tout seul.

Et pour cette requette c’est l’index sur idaction qui est choisi alors que dans ma requête il est en 3eme posistion! Pourquoi n’est ce pas l’index qui commence par idsite qui a été choisi?

Merci pour ce post bien écrit, compréhensible et très instructif, ça change du site de mysql qui explique tout sans rien expliquer

Le produit cartésien ‘brute’ de deux tables de 10,000 lignes donne une table de 100,000,000 lignes

En fait, c’est une question que je me posais depuis longtemps et, même si Google est mon ami, j’ai jamais trouvé la réponse de façon claire .. ni pris le temps d’investiguer ou de faire des tests (honte à moi !!).

Sinon, pour compléter un oubli sur mon commentaire précédent, je reprends Collobian à propos du post : « Excellent, et salutaire. »