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 \| Julien 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. Shopping Time Network - Founder / CTO
mirage \| Vincent 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 \| Julien Administrateur Inscrit le : 09/03/2005	# Le 05/04/2006 à 18:05 Meme dans la colonne ref ? Shopping Time Network - Founder / CTO
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:07 Ouip, toujours "const".
devtribu \| Olivier 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 ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
mirage \| Vincent 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 \| Alexandre 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 \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 05/04/2006 à 18:29 Roh l'autre comment il me pourrit mon topic...
devtribu \| Olivier 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) Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
devtribu \| Olivier 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 Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Limit \| Cyril 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 \| Vincent 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 \| Olivier 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 Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Zalex14 \| Alexandre 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 \| Olivier 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. daevel : infogérance et conseil \|\| moi
Bool \| Olivier 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" daevel : infogérance et conseil \|\| moi
Zalex14 \| Alexandre 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 \| Julien 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) ? Shopping Time Network - Founder / CTO
Zalex14 \| Alexandre 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

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

Shopping Time Network - Founder / CTO

mirage | Vincent
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 | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 05/04/2006 à 18:05

Meme dans la colonne ref ?

Shopping Time Network - Founder / CTO

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:07

Ouip, toujours "const".

devtribu | Olivier
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 ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

mirage | Vincent
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 | Alexandre
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 | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 05/04/2006 à 18:29

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

devtribu | Olivier
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)

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

devtribu | Olivier
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

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Limit | Cyril
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 | Vincent
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 | Olivier
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

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Zalex14 | Alexandre
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 | Olivier
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.

daevel : infogérance et conseil || moi

Bool | Olivier
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"

daevel : infogérance et conseil || moi

Zalex14 | Alexandre
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 | Julien
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) ?

Shopping Time Network - Founder / CTO

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