Bonjour,
Pour répondre à votre message, je me permets quelques précisions aux points que vous évoquez :
"a mon avis la réplication n'est pas ici d'un
grand secours dans la mesure où il n'y a en effet pas les requêtes de type SELECT dans le journal binaire."
C'est pourquoi je propose également l'utilisation du log général qui permet de récupérer l'ensemble des requêtes.
"La seule solution serait d'utiliser MySQL 5.1 puisqu'avec cette version la
journalisation se fait dans les tables mysql.general_log et mysql.slow_log.
Cependant, seule la table mysql.slow_log contient une colonne db.
Bien qu'étant en beta, ca ne devrait pas poser de problème de tester le site
sur MySQL 5.1 en fin de développement."
Je ne comprends pas bien cette idée de "seule solution". Un forum permet de partager et de faire évoluer des idées.
Toutes les esquisses de solutions sont, à mon sens, bonnes à prendre.
J'admets que la réplication n'est pas forcement une solution pertinente dans ce cas (au moins pour les instructions select).
Celle que vous proposez ne permet pas de couvrir tous les aspects du problème puisqu'elle propose de s'appuyer sur le log des requêtes lentes (puisque vous précisez que le log général ne contient pas de colonne db) qui ne fera référence, comme son nom l'indique, qu'aux requêtes lentes (et non pas à toutes les requêtes).
Pour information, le log des requêtes lentes existe également en versions 4.1.x et 5.0.x sous forme de fichier et peut être exploité avec l'utilitaire mysqldumpslow.
Simplement, le log général (ou log des requêtes) contient également une notion de "base utilisée".
Cette trace n'étant pas évidente à analyser, il existe des outils pour l'exploiter et notamment extraire les requêtes d'une base.
Vous pouvez vous rendre à cette adresse :
http://hackmysql.com/mysqlsla
Je suis, évidement, également à l'écoute des "trucs et astuces" sur ce sujet.
A suivre donc...