Discussion :

[zakaa]

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 ?

[Grandal]

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

[zakaa]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[CinePhil]

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

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.

[ericd69]

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...

[zakaa]

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.