Identifiez-vous Devenir membre

Rechercher

Optimisations mySQL

25 réponses

Page 1 2

Auteur	Message
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 17:51 Hello all, Je me suis (enfin) décidé à revoir certaines requêtes mySQL pas super clean ni rapide. Je suis donc passé par un explain via phpMyAdmin pour avoir des conseils d'optimisations mais, malgré la doc sous les yeux et quelques recherches, je ne trouve pas comment optimiser les index et/ou mes requêtes. Pour ne pas déformer le forum, j'ai mis les requêtes et les résultats des explain dans ce fichier . D'après ce que j'ai pû lire, le "using_filesort" est le mal absolu. Or, après avoir essayé de positionner des index sur certains champs, j'ai toujours le même résultat : "using_filesort". Les requêtes ne sont pas particulièrement lentes. Merci à ceux qui pourront me donner un coup de main
Julgates Administrateur Inscrit le : 09/03/2005	# Le 05/04/2006 à 17:54 A priori ajoutes un index sur a.auteur et a.cat et ça devrait être mieux. Beyoung Interactive - Consultant web
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 17:59 Je viens d'ajouter les index sur les 2 champs sur les 2 tables et ça renvoi exactement les mêmes infos pour les 2 requêtes (tout est identique).
Julgates Administrateur Inscrit le : 09/03/2005	# Le 05/04/2006 à 18:05 Meme dans la colonne ref ? Beyoung Interactive - Consultant web
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:07 Ouip, toujours "const".
devtribu Modérateur Inscrit le : 16/06/2005	# Le 05/04/2006 à 18:08 ca m'a pas l'air mauvais comme resultat quelle est la volumetrie des tables ? quel est le temps sql de chaque requete ? Application Beauté-test mobile iPhone iPad Application Beauté-test mobile Android
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:16 Alors, il s'agit d'un même script utilisé 2 fois (sur 2 sites différents). Sur le site A : 4000 messages, 800 sujets, 500 membres, temps de 0,002 secondes pour chaque requêtes Sur le site B : pas encore de messages (pas encore ouvert), le temps de chargement est beaucoup plus important : 0,02 seconde mais il n'y a pas d'index sur la table membres et je récupère plus d'informations (pas optimisé pour l'instant).
Zalex14 Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 18:27 Mdr Je fais exactement la même chos en ce moment . Voillà la mienne : # Query_time: 30 Lock_time: 0 Rows_sent: 2 Rows_examined: 227820 SELECT pseudo_user, id_user, date_message, user.avatar, nbpost, nbtabs, nbdownload, banni, nb_photos, Abonnement_DFV, Moderateur, sujets, titre_message, id_messages, sondage, libelle_message, signature_message, DER_VIS, bloque FROM `messages` INNER JOIN `user` ON (`messages`.`id_user` = `user`.`numero`) WHERE (`parent` = 53997) ORDER BY `sujets` DESC, `date_message` limit 75730,10; Index sur parent/sujets/date_message,id_user et numero evidemment.. Bon là y'a beaucoup de réponse sur ce topic ^^ mais bon ca charge quand même sévère... Si quelqu'un a une idée Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:29 Roh l'autre comment il me pourrit mon topic...
devtribu Modérateur Inscrit le : 16/06/2005	# Le 05/04/2006 à 18:32 2ms par requete et tu veux encore optimiser ! Tu ne pourras pas faire mieux. La seule chose a faire encore c'est d'utiliser le cache de mysql 4. Et tu peux atteindre 0.1 a 0.2 ms / requete (a condition que la table ne change pas trop souvent sinon, c'est pas interessant) Application Beauté-test mobile iPhone iPad Application Beauté-test mobile Android
devtribu Modérateur Inscrit le : 16/06/2005	# Le 05/04/2006 à 18:34 Zalex > les topics a 75000 messages sont une saloperie. Pour ma part, les gros topics, je les bloque et j'invite a en créer un autre. En expliquant que c'est pour optimiser le serveur, ca passe sans probleme Application Beauté-test mobile iPhone iPad Application Beauté-test mobile Android
Limit Membre Inscrit le : 11/05/2005	# Le 05/04/2006 à 18:34 Zalex14 a dit : Mdr Je fais exactement la même chos en ce moment . Voillà la mienne : # Query_time: 30 Lock_time: 0 Rows_sent: 2 Rows_examined: 227820 SELECT pseudo_user, id_user, date_message, user.avatar, nbpost, nbtabs, nbdownload, banni, nb_photos, Abonnement_DFV, Moderateur, sujets, titre_message, id_messages, sondage, libelle_message, signature_message, DER_VIS, bloque FROM `messages` INNER JOIN `user` ON (`messages`.`id_user` = `user`.`numero`) WHERE (`parent` = 53997) ORDER BY `sujets` DESC, `date_message` limit 75730,10; Index sur parent/sujets/date_message,id_user et numero evidemment.. Bon là y'a beaucoup de réponse sur ce topic ^^ mais bon ca charge quand même sévère... Si quelqu'un a une idée Rows_examined: 227820 c'est ca ton prob Forum Gratuit - Blog gratuit
mirage Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:34 C'est le résultats donné par l'explain qui me chagrine. C'est pas important ce "using_filesort" ?
devtribu Modérateur Inscrit le : 16/06/2005	# Le 05/04/2006 à 18:37 avec 2ms sur une jointure triée, c'est parfait le using_filesort me parait obligatoire dans ce cas, mais comme il ne penalise pas les perf, pas de souci Application Beauté-test mobile iPhone iPad Application Beauté-test mobile Android
Zalex14 Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 18:38 Limit a dit : Rows_examined: 227820 c'est ca ton prob Chuis d'accord, mais comment l'éviter ? C'est ma jointure qui est pourrie ? Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
Bool Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 18:38 Pour moi le seul problème avec cette requete c'est le "ORDER BY". Pour le moment ça passe car la table est petite, mais ça ne durera pas. Et précalculer un champ "position" n'est pas évident, surtout avec des tables MyISAM. Google is watching you.
Bool Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 18:53 Pour le cas des "messages", précalculer la position est au contraire assez simple, vu que l'ordre des messages ne change jamais... au pire si tu supprimes un message, tu fais un UPDATE de tous les champs suivants... PS : le but est de se retrouver avec un "WHERE position between 1 and 25 order by position" au lieu du "order by date limit 0,25" Google is watching you.
Zalex14 Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 19:10 Merci Bool, je vais tester ça PS : Désolé Vinc' (Message édité le 05-04-2006 à 19h15 par Zalex14) Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
Julgates Administrateur Inscrit le : 09/03/2005	# Le 05/04/2006 à 20:40 Zalex as-tu un index parmi ceux que tu cites qui serait multiple (un clef pour deux champs) ? Beyoung Interactive - Consultant web
Zalex14 Modérateur Inscrit le : 09/05/2005	# Le 05/04/2006 à 20:47 non ils sont tous uniques. J'ai toujours entendu dire que les index multiples permettent de gagner du temps sur certaines requetes quand les champs filtrés correspondent exactement aux champs de l'index multiple, mais ralentissent franchement pour toutes les autres. Je sais pas si c'est vrai mais généralement j'évite les multiples pour couvrir le maximum de requete différentes. Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

Auteur

Message

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 17:51

Hello all,

Je me suis (enfin) décidé à revoir certaines requêtes mySQL pas super clean ni rapide.

Je suis donc passé par un explain via phpMyAdmin pour avoir des conseils d'optimisations mais, malgré la doc sous les yeux et quelques recherches, je ne trouve pas comment optimiser les index et/ou mes requêtes.

Pour ne pas déformer le forum, j'ai mis les requêtes et les résultats des explain dans ce fichier .

D'après ce que j'ai pû lire, le "using_filesort" est le mal absolu. Or, après avoir essayé de positionner des index sur certains champs, j'ai toujours le même résultat : "using_filesort". Les requêtes ne sont pas particulièrement lentes.

Merci à ceux qui pourront me donner un coup de main

Julgates
Administrateur

Inscrit le : 09/03/2005

# Le 05/04/2006 à 17:54

A priori ajoutes un index sur a.auteur et a.cat et ça devrait être mieux.

Beyoung Interactive - Consultant web

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 17:59

Je viens d'ajouter les index sur les 2 champs sur les 2 tables et ça renvoi exactement les mêmes infos pour les 2 requêtes (tout est identique).

Julgates
Administrateur

Inscrit le : 09/03/2005

# Le 05/04/2006 à 18:05

Meme dans la colonne ref ?

Beyoung Interactive - Consultant web

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:07

Ouip, toujours "const".

devtribu
Modérateur

Inscrit le : 16/06/2005

# Le 05/04/2006 à 18:08

ca m'a pas l'air mauvais comme resultat
quelle est la volumetrie des tables ?
quel est le temps sql de chaque requete ?

Application Beauté-test mobile iPhone iPad
Application Beauté-test mobile Android

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:16

Alors, il s'agit d'un même script utilisé 2 fois (sur 2 sites différents).

Sur le site A : 4000 messages, 800 sujets, 500 membres, temps de 0,002 secondes pour chaque requêtes

Sur le site B : pas encore de messages (pas encore ouvert), le temps de chargement est beaucoup plus important : 0,02 seconde mais il n'y a pas d'index sur la table membres et je récupère plus d'informations (pas optimisé pour l'instant).

Zalex14
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 18:27

Mdr
Je fais exactement la même chos en ce moment .

Voillà la mienne :
# Query_time: 30 Lock_time: 0 Rows_sent: 2 Rows_examined: 227820

SELECT
pseudo_user, id_user, date_message, user.avatar, nbpost, nbtabs, nbdownload, banni, nb_photos, Abonnement_DFV, Moderateur, sujets, titre_message, id_messages, sondage, libelle_message, signature_message, DER_VIS, bloque
FROM `messages`
INNER JOIN `user` ON (`messages`.`id_user` = `user`.`numero`)
WHERE (`parent` = 53997)
ORDER BY `sujets` DESC, `date_message` limit 75730,10;

Index sur parent/sujets/date_message,id_user et numero evidemment..
Bon là y'a beaucoup de réponse sur ce topic ^^ mais bon ca charge quand même sévère...
Si quelqu'un a une idée

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:29

Roh l'autre comment il me pourrit mon topic...

devtribu
Modérateur

Inscrit le : 16/06/2005

# Le 05/04/2006 à 18:32

2ms par requete et tu veux encore optimiser !
Tu ne pourras pas faire mieux.

La seule chose a faire encore c'est d'utiliser le cache de mysql 4. Et tu peux atteindre 0.1 a 0.2 ms / requete (a condition que la table ne change pas trop souvent sinon, c'est pas interessant)

Application Beauté-test mobile iPhone iPad
Application Beauté-test mobile Android

devtribu
Modérateur

Inscrit le : 16/06/2005

# Le 05/04/2006 à 18:34

Zalex > les topics a 75000 messages sont une saloperie.
Pour ma part, les gros topics, je les bloque et j'invite a en créer un autre. En expliquant que c'est pour optimiser le serveur, ca passe sans probleme

Application Beauté-test mobile iPhone iPad
Application Beauté-test mobile Android

Limit
Membre

Inscrit le : 11/05/2005

# Le 05/04/2006 à 18:34

Zalex14 a dit :
Mdr

Je fais exactement la même chos en ce moment .

Voillà la mienne :
# Query_time: 30 Lock_time: 0 Rows_sent: 2 Rows_examined: 227820

SELECT
pseudo_user, id_user, date_message, user.avatar, nbpost, nbtabs, nbdownload, banni, nb_photos, Abonnement_DFV, Moderateur, sujets, titre_message, id_messages, sondage, libelle_message, signature_message, DER_VIS, bloque
FROM `messages`
INNER JOIN `user` ON (`messages`.`id_user` = `user`.`numero`)
WHERE (`parent` = 53997)
ORDER BY `sujets` DESC, `date_message` limit 75730,10;

Index sur parent/sujets/date_message,id_user et numero evidemment..
Bon là y'a beaucoup de réponse sur ce topic ^^ mais bon ca charge quand même sévère...
Si quelqu'un a une idée

Rows_examined: 227820
c'est ca ton prob

Forum Gratuit - Blog gratuit

mirage
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:34

C'est le résultats donné par l'explain qui me chagrine. C'est pas important ce "using_filesort" ?

devtribu
Modérateur

Inscrit le : 16/06/2005

# Le 05/04/2006 à 18:37

avec 2ms sur une jointure triée, c'est parfait
le using_filesort me parait obligatoire dans ce cas, mais comme il ne penalise pas les perf, pas de souci

Application Beauté-test mobile iPhone iPad
Application Beauté-test mobile Android

Zalex14
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 18:38

Limit a dit :
Rows_examined: 227820
c'est ca ton prob

Chuis d'accord, mais comment l'éviter ? C'est ma jointure qui est pourrie ?

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 18:38

Pour moi le seul problème avec cette requete c'est le "ORDER BY". Pour le moment ça passe car la table est petite, mais ça ne durera pas.

Et précalculer un champ "position" n'est pas évident, surtout avec des tables MyISAM.

Google is watching you.

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 18:53

Pour le cas des "messages", précalculer la position est au contraire assez simple, vu que l'ordre des messages ne change jamais... au pire si tu supprimes un message, tu fais un UPDATE de tous les champs suivants...

PS : le but est de se retrouver avec un "WHERE position between 1 and 25 order by position" au lieu du "order by date limit 0,25"

Google is watching you.

Zalex14
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 19:10

Merci Bool, je vais tester ça

PS : Désolé Vinc'

(Message édité le 05-04-2006 à 19h15 par Zalex14)

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

Julgates
Administrateur

Inscrit le : 09/03/2005

# Le 05/04/2006 à 20:40

Zalex as-tu un index parmi ceux que tu cites qui serait multiple (un clef pour deux champs) ?

Beyoung Interactive - Consultant web

Zalex14
Modérateur

Inscrit le : 09/05/2005

# Le 05/04/2006 à 20:47

non ils sont tous uniques.
J'ai toujours entendu dire que les index multiples permettent de gagner du temps sur certaines requetes quand les champs filtrés correspondent exactement aux champs de l'index multiple, mais ralentissent franchement pour toutes les autres.
Je sais pas si c'est vrai mais généralement j'évite les multiples pour couvrir le maximum de requete différentes.

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

Page 1 2

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.