Long Query Time

[equids]

Je voudrais savoir, pour le fichier Long Query Time qui enregistre les requetes SQL longues, quelle est l'unité du "Query_time" ?

On m'a dit que c'était des secondes, mais je m'étonne, parceque je vois des Query_time de 56, ca voudrait dire que la page qui utilise la requete en question devrait mettre plus de 56 secondes a s'afficher non ? or ce n'est pas le cas.

J'ai pensé au millisecondes, mais je ne sais pas vraiment,

merci de m'éclairer

[petit-ourson]

A priori ce sont des secondes.

[equids]

Oui, c'est ce qu'on m'a dit, mais pourquoi alors la page qui contient la FAMEUSE requete censée durer 56 secondes (c'est énorme !), s'affiche assez rapidement ?

[petit-ourson]

A chaque accès de la page elle est longue ? Peut-être que parfois elle se trouve dans le cache de mySQL donc rapide.

[equids]

Je ne sais pas si elle longue a chaque fois,

mais je suis très étonné de voir des requetes qui prennent 56 secondes quand meme,

tout simplement parceque je n'ai jamais eu une page qui mettait autant de temps à s'afficher.

Et une requete peut se mettre dans le cache sans qu'on l'ait programmé ?

Je veux dire que je n'ai pas mis en place de cache, il y en a un par défaut ?

[Kioob]

Oui, depuis MySQL 4.0 il y a un cache de requête "automatique".

Pour ce qui est du temps d'exécution, 56 secondes c'est très court dans le monde des bases de données. Certaines requêtes peuvent durer plusieurs heures.

[equids]

Je ne comprends pas

Comment une requete peut durer des heures ??

La réponse est donnée après ces heures ? le site met combien de temps a afficher ces pages, je pige pas la.

[Kioob]

Note que je n'ai pas dit qu'il s'agissait d'un site Internet... Quand il y a énormément de données (des dizaines, voir des centaines de Go), et que la requête est complexe (beaucoup de jointures, des group by, etc) ça peut vite monter.

Encore plus si la requête est "mal faite" et/ou que les indexes nécessaires ne sont pas présents.

Pour ce qui est du "comment ça se passe sur le site web", bah c'est simple : l'utilisateur va voir ailleurs avant que la page ne s'affiche... ou encore Apache abandonne et affiche une erreur. Il n'empêche que coté MySQL la requête continue de tourner, et apparaîtra probablement dans le log "slow query" à la fin.

[equids]

C'est vrai,

mais est ce qu'une requete sur internet en Mysql, qui dure 56 secondes, doit impliquer une page qui s'affiche en autant de temps ?

Ca me semble énorme, surtout qu'aucune page ne met ce genre de temps a s'afficher, 3 sec tout au plus...

[Kioob]

mais est ce qu'une requete sur internet en Mysql, qui dure 56 secondes, doit impliquer une page qui s'affiche en autant de temps ?

Si ton script PHP lance cette requête, il ne pourra rien faire d'autre tant qu'elle n'est pas terminée... Donc s'il le fait avant d'afficher la page, celle ci mettra 56 secondes à s'afficher oui... bien que l'internaute sera probablement parti ailleurs depuis longtemps.

Pour ce qui est du fait qu'aucune page ne mette autant de temps d'après toi, justement tes logs disent le contraire... et comme l'a expliqué Mr Nounours le résultat est probablement en cache, donc tu ne t'en aperçois pas.

Il se peut aussi que ce soit un ralentissement ponctuel à cause de la procédure de sauvegarde, d'une autre requête qui verrouille la table, voir même un ralentissement global du serveur.

[equids]

Merci de ta réponse,

c'est clair que 56 secondes, personne ne resterait devant !

Ce qui est étonnant c'est que la quasi totalité de ces requetes longues (bon en gégéral c'est plus de l'ordre de 2 secondes), sont des

SELECT COUNT(*) FROM ...

Je croyais que c'était la meilleure manière de compter des résultats, mais peut etre que j'ai tord ?

[Kioob]

Si la table ou la base est verrouillée (à cause d'une modification en cours dans la table ou d'un LOCK), la requête devra attendre : normalement dans le log "slow query", le "locked time" est indiqué. Il est à 0 ici ?

Après ça dépend de plusieurs facteurs... un count(*) sans clause where sur une table MyISAM est effectivement immédiat. Mais s'il y a des clauses WHERE ou s'il s'agit d'INNODB, MySQL sera bien obligé de vraiment compter les lignes en question.

Pour ce qui est de la meilleure manière de faire, oui c'est bien souvent le cas. Mais ça ne veut pas dire que c'est forcément "hyper rapide".

[equids]

Je voudrais premièrement te remercier de tes réponses, c'est très sympa.

Sinon, pour la requete COUNT, il y a une clause WHERE avec 3 champs VARCHAR indéxés.

Peut etre qu'en numériques ca prendrai moins de temps ?

Et excuse moi, mais je n'ai aps compris le cas de la réponse immédiate. C'est si il n'y a aucune clause ?

[Kioob]

Pour savoir pourquoi une requête est lente, la meilleure solution est bien souvent de faire un EXPLAIN de la requête. Ainsi tu sauras "par où et comment" MySQL passe pour répondre à la requête.

Pour ce qui est de la réponse immédiate, oui c'est seulement s'il n'y a aucune clause et que la table est stockée au format MYISAM.

[equids]

Ou est ce que tu vois tout ce chemin parcouru par MySQL lors d'un EXPLAIN

Moi j'obtiens seulement une ligne qui ressemble à ça :

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE forum ref cat,type,valid type 252 const 39866 Using where

[Kioob]

Et bien là on voit qu'on il n'utilise qu'une seule table (forum), l'index "type", et qu'il parcourt 39'866 lignes pour répondre à ta requête.

[equids]

Ah ok, quand tu parlais de "chemins", c'était surement par rapport aux requetes avec jointures non ?

[Kioob]

J'ai juste indiqué "par où et comment"