Discussion :

[PBR]

Bonjour à tous,
(j'espère poster dans le bon sous-forum).

Voilà 2 jours que je cherche désespérément une solution...

Mon environnement :
- 1 poste de développement sous Windows (XP)
- 1 poste de production sous Linux (RH4)

Les deux machines sont équipées d'une base mySQL 5, qui sont bien entendu identiques.
Les tables sont en INNODB. Les données sont exploitées via une appli en php.

Mon souci : j'ai une grosse requete pour générer un "export utilisateur" dans l'appli (SELECT avec une vingtaine de jointures) qui s'executait bien jusqu'à maintenant. Le problème, c'est que la base à grossie et les temps de traitement deviennent très très lourds.

Je ne parle ici que de la partie exécution SQL pure et dure (côté php j'ai déjà réduit les temps de traitement).

Voici ce que j'ai modifié pour améliorer les temps d'exécution MySQL :
- J'ai ajouter des indexes
- J'ai modifié le fichier de config my.cnf/ini en allouant 256M au paramètre innodb_buffer_pool_size.

Le temps d'exécution de la requête a considérablement diminué... sous windows.
Mon problème, c'est qu'en affectant exactement la même config sous linux, je n'ai pas du tout les mêmes résultats : Une même requête met 2 sec sous windows, contre presque 30 sec sous linux...

A priori, ce n'est pas un problème de "syntaxe" de la requête puisqu'elle s'exécutre rapidement sous XP, mais véritablement un problème de configuration du serveur.

Je précise que les 2 machines sont exactements les mêmes (marque, CPU, mémoire identiques) et qu'aucune autre appli ne tourne dessus.

Je ne vois vraiment plus quoi faire.

Auriez-vous éventuellement une piste pour m'aider SVP ?

Merci d'avance !


PBR

[Sivrît]

Sait-on jamais, les version de MySQL sont exactement les mêmes ?

La première chose à faire serait de faire un "EXPLAIN" de la requête sur chaque machine, pour voir si MySQL utilise le même plan d'exécution. Les machines peuvent avoir des statistiques différentes sur leurs index. Ce serait l'occasion de faire un "analyse table" sur les tables.

Sinon reste à voir le détail de la configuration, idéalement avec des "show global variables" pour être certain de c'est bien ce qui tourne. Les variables qui me viennent à l'esprit sont surtout :

Code :

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

1
2
3
key_buffer_size
max_heap_table_size
tmp_table_size

Peut-être "innodb_autoextend_increment" et "innodb_data_file_path", des fois que le tablespace soit plus fragmenté sur une machine. Aussi tester les deux à froid (l'une avait peut-être un cache plus favorable).

Bonne chance.

[PBR]

Bonjour et merci pour ton aide,

Pour répondre à ta question, les deux versions ne sont pas exactement identiques :

Sur le poste Windows : 5.1.30-communauty
Sur le poste Linux : 5.0.24a-community-nt

Tu crois que ça peux changer quelque chose ?

En ce qui concerne le EXPLAIN, il donne bien un même résultat sur les 2.
J'ai fait un ANALYSE aussi (mais du coup est-ce utile ?).

Pour les variables, je les ai en effet déjà toutes comparées vu que je ne voyais pas d'où ça venait (environ 250 ), mais elles sont bien toutes identiques.

Du coup je commence à sécher et je tente des "trucs"...

J'ai essayé de faire un OPTIMIZE sur une de mes principales tables et là surprise : sous Windows, pas de problème, mais sous Linux "Table does not support optimize, doing recreate + analyze instead".
Avez-vous une idée de quoi ça pourrait venir ?
(je précise que j'ai utilisé le même script pour créer les 2 bases structures et données)

Deuxièmement, il n'y a peut-être aucun rapport mais je pose la question quand même : ne serait-ce pas une histoire de jeu de caractères ?
Ma base est en interclassement Latin_1 (sur les 2 postes du coup),
Sur le mysql/Windows, c'est également le jeu de caractères par défaut, mais mysql/Linux est lui en UTF8... ?

Ces deux choses n'ont peut-être aucun rapport, mais si desfois ça peut lancer sur d'autres idées je suis preneur

Merci !