Comportement different entre 2 versions Mysql

Bonjour,

J'ai une application qui fonctionne avec la version 5.0.77 de Mysql.

J'ai installé la même application pour un client, qui à lui une version 5.1.52.


J'ai un soucis sur une requête en particulier, qui provoque chez lui l'erreur suivante si le nombre de ligne renvoyé est trop important :
Incorrect key file for table '/tmp/#sql_2dbe_0.MYI'; try to repair it

Après plusieurs vérifications (+REPAIR, OPTIMIZE, suppression et création de la table ...) je me suis aperçu que l'EXPLAIN sur cette requête donnait un résultat différent, et que certains index n’était pas utilisés dans son cas.
Même dans le cas ou la requête fonctionne (quand elle renvoi moins de lignes) elle est beaucoup plus longue.

Je suis en train de vérifier les variables, mais à priori pas de différence non plus.

Est-ce que vous avez connaissance de fonctionnement différent entre ces deux versions de Mysql ?

Bonjour

Il m'est arrivé d'avoir ce type de message quand le répertoire ou Mysql place ses fichiers temporaires n'est pas la ou a un problème de droits.

Tu pourrais tenter de vérifier et changer le tmpdir (syntaxe a vérifier) en le mettant dans le My.ini de la 5.5.

Francis

Ok, je vais vérifier ca.
Ca expliquerait peut-être le plantage, mais pas la difference sur l'explain, non ?

Le tmpdir est à /tmp/ dans mon cas, à /tmp sur la version de mon client...

Les autres variables qui différent :
-- tmp table size
moi :33 554 432
lui : 16 777 216

-- max join size
moi :4 294 967 295
lui : 18446744073709551615 (donc a priori 64 bits ?)

J'attends l'admin pour vérifier ca avec lui.

Petite précision, sur ma version, je peux reproduire le même explain en virant un des index.Dans ce cas la requête est trés longue, mais ne plante pas.

Petite question au passage ... peut être idiote, mais je veux être sur ^^.
Mes tables ont beaucoup plus d'enregistrements que celles de mon client, est-ce que cela peu modifier (en mieux !) le résultat de l'explain ?

L'explain, si ca peu aider :

MOI :

Code:

---

1 2 3 4 5 6

id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE task index idEnvoi,idEnvoi_id idEnvoi_id 8 NULL 1032049 1 SIMPLE envois eq_ref PRIMARY,date_lance PRIMARY 4 task.idEnvoi 1 Using where 1 SIMPLE messages eq_ref PRIMARY PRIMARY 4 envois.idMessage 1 1 SIMPLE sites eq_ref PRIMARY PRIMARY 4 messages.idSite 1

---

LUI:

Code:

---

1 2 3 4 5 6

id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE task ALL idEnvoi,idEnvoi_id NULL NULL NULL 465701 Using temporary; Using filesort 1 SIMPLE envois ALL PRIMARY,date_lance NULL NULL NULL 4 Using where; Using join buffer 1 SIMPLE messages eq_ref PRIMARY PRIMARY 4 envois.idMessage 1 1 SIMPLE sites eq_ref PRIMARY PRIMARY 4 messages.idSite 1

---

Apparemment, chez ton client, certains index ne sont pas utilisés, ce qui pourrait s'expliquer par :

Citation:

---

Mes tables ont beaucoup plus d'enregistrements que celles de mon client

---

L'optimiseur a peut-être estimé qu'il était inutile d'utiliser l'index et qu'il serait plus rapide de parcourir toute la table.

tu as 4go de buffer pour les jointures... et lui 4g fois ta taille lol

c'est des réglages... rigolos...

après pour les indexes sans voir la structure des tables concernées et les requêtes dur à dire...

J'ai refait des tests avec le même volume de données, rien ne change.

En dernier recours j'ai forcé l'utilisation des indexes, avec STRAIGHT_JOIN et FORCE INDEX.
On arrive à un résultat identique sur l'explain et au niveau des performances.

Le temps de passer ça en prod, et je continu mes tests pour trouver ce qui ne va pas.