Discussion :

[renaudjuif]

Bonjour,

J'ai un bug assez bizarre : pour une même requête sur 2 bases quasiment identiques, dans 1 base la requête est exécutée en 2 secondes, et dans l'autre en 16 secondes...
Il semble y avoir un problème sur les index :
un "EXPLAIN SELECT..." me retourne :
rows : 405 sur une table de 73'000 enregistrements
et
rows : 16 sur la même table (dans l'autre BDD) mais qui a 310'000 enregistrements...

J'ai regardé la structure des 2 tables et les index utilisés :

les index n'ont aucune cardinalité dans la base qui a le meilleur temps de réponse, tandis que dans l'autre base, tous les index de la table ont une cardinalité. Est-ce que ça a un rapport ?
Comment corriger ça ? je suppose que c'est le nombre de lignes (405) qui pénalise les temps de réponse...

Merci de vos éclaircissements;

[berceker united]

Il peut y avoir plusieurs raison. Le type de moteur, les enregistrements ainsi que le nombre. 16 secondes je trouve que c'est enorme.

[Sivrît]

Il faudrait voir la requête... C'est bien sur la plus petite table que la requête est la plus lente ?

Sinon je crois que les valeurs données par EXPLAIN sont là à titre indicatif et correspondent aux estimations de mysql (il faut faire des SELECT partiels soi même pour voir combien de lignes on a réellement à chaque étape). Il est possible que les métriques étant différentes mysql opte pour des indexes différents, ou un autre ordre. EXPLAIN donne bien les mêmes indexes utilisés dans deux cas ?

Sinon s'il y a une ou des jointures, avoir 400 résultats au lieu de 16 sur la première table peut faire très mal.

[vmolines]

Peut-être que les statistiques des indexes ne sont pas à jour et erronés sur une des tables. Du coup MySQL ferait un un mauvais plan de requête.

Un petit ANALYZE TABLE sur les deux tables pour les mettre sur un pied d'égalité quant à la justesse des données de l'index.

edit : question, c'est quoi la cardinalité d'un index ?