Mysql5 ?

3 réponses

Auteur	Message
TomPascal \| Membre Inscrit le : 08/11/2006	# Le 08/02/2008 à 02:16 Bonjour, Je viens de migrer un peu dans l'urgence un forum sur un nouveau serveur en mysql 5.0 (j'étais en release1 OVH avant, donc en mysql 3.23) Je remarque que certaines requêtes sont anormalement longues alors que mes champs sur les tables (au format myisam) sont correctement indexés. Par exemple, cette requête : EXPLAIN SELECT topics.numtopic, forum.titre, forum.corps, topics.niveau, forum.date FROM topics LEFT JOIN forum ON topics.numtopic = forum.numtopic AND forum.parent = '1' WHERE topics.forum != '6' ORDER BY topics.numtopic DESC LIMIT 20 Donne sur l'ancien serveur le schéma suivant : table type possible_keys key key_len ref rows Extra topics index NULL PRIMARY 4 NULL 173413 where used forum ref parent,numtopic numtopic 4 topics.numtopic 8 where used Alors que sur le nouveau : id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE topics range forum forum 1 NULL 172319 Using where; Using filesort 1 SIMPLE forum ref parent,numtopic numtopic 4 ilemaths.topics.numtopic 9 Je ne comprend pas pourquoi il n'utilise pas les indexes à disposition et me sort un filesort (qui prend beaucoup de temps forcément...) Est-ce que quelqu'un saurait m'expliquer mon erreur ? comment faire pour corriger le tir ? Merci pour vos éventuelles suggestions. Archipel Web Conception, réalisation, référencement de sites internet.
TomPascal \| Pascal Membre Inscrit le : 08/11/2006	# Le 08/02/2008 à 02:25 Euh, le schéma fonctionne mieux en mysql5 si j'écris SELECT topics.numtopic, forum.titre, forum.corps, topics.niveau, forum.date FROM topics LEFT JOIN forum ON ( topics.numtopic = forum.numtopic AND forum.parent = '1' ) WHERE topics.forum != '6' Bon, je vais creuser un peu et analyser le log de slow_query là... (je crois qu'il est trop tard pour moi pour avoir les idées claires ;)) Archipel Web Conception, réalisation, référencement de sites internet.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 08/02/2008 à 11:20 Hello, un truc tout bete pour commencer : as tu tenter un "analyze table" sur le nouveau serveur ? Parfois l'optimizeur MySQL se vautre un peu dans ses choix tant que l'analyze n'est pas fait. J'ai une requête qui est passé de 2 secondes à 0.02ms, juste à cause de ça : MySQL se tapait toute la table "pensant" qu'elle était petite, alors que ce n'était pas du tout le cas. daevel : infogérance et conseil \|\| moi
TomPascal \| Pascal Membre Inscrit le : 08/11/2006	# Le 08/02/2008 à 14:11 Bonjour Bool, Oui tu dois avoir raison : j'avais pas mal de slow_queries loggués hier juste après la migration et là j'en ai déjà beaucoup moins. J'ai aussi lancé une analyse sur toutes les tables et en effet désormais le schéma retourné pour la même requête (sans les parenthèses) utilise bien les indexes, comme sur mon ancien serveur... Je n'étais pas conscient que pour des grosses bases de données comme ça il fallait compter avec un temps d'adaptation ou d'apprentissage du SGBD (et je n'ai pas l'habitude d'utiliser ANALYSE, je le saurais désormais Merci de ton message. Archipel Web Conception, réalisation, référencement de sites internet.

Auteur

Message

Inscrit le : 08/11/2006

# Le 08/02/2008 à 02:16

Bonjour,

Je viens de migrer un peu dans l'urgence un forum sur un nouveau serveur en mysql 5.0 (j'étais en release1 OVH avant, donc en mysql 3.23)

Je remarque que certaines requêtes sont anormalement longues alors que mes champs sur les tables (au format myisam) sont correctement indexés.

Par exemple, cette requête :
EXPLAIN SELECT topics.numtopic, forum.titre, forum.corps, topics.niveau, forum.date
FROM topics
LEFT JOIN forum ON topics.numtopic = forum.numtopic
AND forum.parent = '1'
WHERE topics.forum != '6'
ORDER BY topics.numtopic DESC
LIMIT 20

Donne sur l'ancien serveur le schéma suivant :
table type possible_keys key key_len ref rows Extra
topics index NULL PRIMARY 4 NULL 173413 where used
forum ref parent,numtopic numtopic 4 topics.numtopic 8 where used

Alors que sur le nouveau :
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE topics range forum forum 1 NULL 172319 Using where; Using filesort
1 SIMPLE forum ref parent,numtopic numtopic 4 ilemaths.topics.numtopic 9

Je ne comprend pas pourquoi il n'utilise pas les indexes à disposition et me sort un filesort (qui prend beaucoup de temps forcément...)

Est-ce que quelqu'un saurait m'expliquer mon erreur ? comment faire pour corriger le tir ?

Merci pour vos éventuelles suggestions.

Archipel Web Conception, réalisation, référencement de sites internet.

TomPascal | Pascal
Membre

Inscrit le : 08/11/2006

# Le 08/02/2008 à 02:25

Euh, le schéma fonctionne mieux en mysql5 si j'écris

SELECT topics.numtopic, forum.titre, forum.corps, topics.niveau, forum.date
FROM topics
LEFT JOIN forum ON ( topics.numtopic = forum.numtopic
AND forum.parent = '1' )
WHERE topics.forum != '6'

Bon, je vais creuser un peu et analyser le log de slow_query là... (je crois qu'il est trop tard pour moi pour avoir les idées claires ;))

Archipel Web Conception, réalisation, référencement de sites internet.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 08/02/2008 à 11:20

Hello,

un truc tout bete pour commencer : as tu tenter un "analyze table" sur le nouveau serveur ?
Parfois l'optimizeur MySQL se vautre un peu dans ses choix tant que l'analyze n'est pas fait.

J'ai une requête qui est passé de 2 secondes à 0.02ms, juste à cause de ça : MySQL se tapait toute la table "pensant" qu'elle était petite, alors que ce n'était pas du tout le cas.

daevel : infogérance et conseil || moi

TomPascal | Pascal
Membre

Inscrit le : 08/11/2006

# Le 08/02/2008 à 14:11

Bonjour Bool,

Oui tu dois avoir raison : j'avais pas mal de slow_queries loggués hier juste après la migration et là j'en ai déjà beaucoup moins.

J'ai aussi lancé une analyse sur toutes les tables et en effet désormais le schéma retourné pour la même requête (sans les parenthèses) utilise bien les indexes, comme sur mon ancien serveur...
Je n'étais pas conscient que pour des grosses bases de données comme ça il fallait compter avec un temps d'adaptation ou d'apprentissage du SGBD (et je n'ai pas l'habitude d'utiliser ANALYSE, je le saurais désormais

Merci de ton message.

Archipel Web Conception, réalisation, référencement de sites internet.

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.