Commençons par l’installation du script. Rien de plus simple, il vous suffit pour commencer de télécharger et de décompresser une archive de l’outil, disponible ici. Ensuite, des classiques

$ perl Makefile.PL
$ make
# make install

vous permettent d’installer le script. Notez, point agréable, qu’une page de man est intégrée. Si vous cherchez la syntaxe d’une option, un man mysqlsla vous dispensera donc bien souvent d’aller faire un tour sur le site du projet.

mysqlsla est plus généraliste que mysqldumpslow dans le sens où il est capable de traiter tout type de journal (requêtes lentes, mais aussi journal binaire ou journal général, ou encore journal défini par l’utilisateur). Les principes que nous allons voir dans cet article pour les requêtes lentes sont aussi valables pour les autres types de journaux.

L’idée de base de mysqlsla est de pouvoir analyser des fichiers journaux en leur appliquant éventuellement des filtres afin de ne garder que certains événements et d’émettre un rapport personnalisable présentant les résultats de cette analyse. Dans cet article nous allons seulement regarder les capacités de filtrage de mysqlsla et pas la manière de produire un rapport personnalisé, puisque le rapport par défaut nous convient très bien.

Pour un premier essai, lançons mysqlsla sans paramètre particulier à part l’option lt (comme log type) qui indique au script que le fichier passé est un journal de requêtes lentes. Cette option n’est en réalité pas indispensable car mysqlsla sait détecter automatiquement le type de journal :

$ mysqlsla -lt slow msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

________________________________________________ 001 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

________________________________________________ 002 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

A première vue, ce rapport ressemble à celui de mysqldumpslow avec un regroupement des requêtes similaires. Le rapport est cependant plus complet car pour chaque groupe, nous avons les valeurs minimales, moyennes et maximales ainsi qu’une information très intéressante sur le poids relatif de chaque groupe, ce qui permet de cibler facilement les requêtes qui ont le plus contribué au temps de réponse ou qui ont examiné le plus de lignes.

Autre point à noter : pour chaque groupe de requêtes, mysqlsla nous présente une vue abstraite de la requête, c’est-à-dire une requête générique où les paramètres qui varient entre les requêtes du groupe sont remplacés par N pour un nombre ou S pour une chaîne de caractères, mais aussi un exemple de requête avec des vrais paramètres. C’est un bon point par rapport à mysqldumpslow puisqu’il est facile avec l’exemple de regarder le plan d’exécution donné par la commande EXPLAIN.

Intéressons-nous aux 4 questions que nous nous étions posées lors de l’article précédent, qui vont nous permettre de voir comment utiliser les méta-données des requêtes pour trier ou filtrer.

Chaque requête dans le journal possède un certain nombre de méta-données, comme le temps d’exécution ou le nombre de lignes examinées. Il existe également des méta-données dérivées, comme la moyenne des temps d’exécution pour un groupe de requêtes. Les méta-données disponibles dépendent du type de journal considéré, et tout est détaillé dans la page de la documentation consacrée aux filtres.

mysqlsla nous permet de trier les résultats du rapport selon n’importe quelle méta-donnée avec l’option --sort.

Ceci va nous permettre de répondre aux 2 premières questions :

Quel est le groupe de requêtes ayant le plus long temps de réponse ?

$ mysqlsla -lt slow --sort t_sum msandbox-slow.log

Ici l’affichage est exactement celui que nous avions sans l’option --sort. C’est normal car pour les journaux de requêtes lentes, mysqlsla applique par défaut l’option --sort t_sum !

Quel est le groupe de requêtes ayant le plus grand nombre d’occurrences ?

$ mysqlsla -lt slow --sort c_sum msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 'c_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

_______________________________________________ 001 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

________________________________________________ 002 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

L’utilisation des filtres va nous permettre de répondre aux 2 dernières questions. Il faut savoir que mysqlsla dispose de deux types de filtres : le premier type permet de filtrer sur les méta-données des entrées du journal alors que le second permettre de sélectionner ou d’exclure un ou plusieurs types de requêtes. Ces deux types de filtres peuvent bien sûr être combinés afin de répondre à des questions complexes.

Les filtres sur les méta-données s’écrivent avec l’option --meta-filter (ou -mf en abrégé), comme par exemple -mf "db=sakila" pour ne conserver que les requêtes sur la base sakila ou -mf "db=sakila,c_sum>5" pour ne conserver que les requêtes sur la base sakila qui apparaissent au moins 6 fois.

Il est facile avec cette option de répondre à la 3è question :
Quelles sont les requêtes qui prennent plus de x secondes ?
En positionnant x à 0.1s, on obtient le résultat suivant :

$ mysqlsla -lt slow -mf "t>0.1" msandbox-slow.log
Report for slow logs: msandbox-slow.log
1 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 0, Rows Examined 16.04k

________________________________________________ 001 ___
Count : 1 (100.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (100.00%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (100.00%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (1) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;


Enfin nous allons nous servir des filtres sur les requêtes (option --statement-filter ou -sf) pour répondre à la 4è question :
Comment ne conserver que les requêtes SELECT ?

$ mysqlsla -lt slow -sf "+SELECT" msandbox-slow.log
Report for slow logs: msandbox-slow.log
3 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 0 s, Lock 0 s, Rows sent 1.80k, Rows Examined 48.13k

________________________________________________ 001 ___
Count : 3 (100.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (100.00%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (100.00%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (3) of all users

Query abstract:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

Et voilà, notre (courte) exploration de mysqlsla est terminée ! Ces quelques exemples ont montré que mysqlsla est extrêmement flexible comparé à mysqldumpslow, ce qui en fait un très bon choix en tant outil d’analyse de journaux MySQL. Quels sont les inconvénients de mysqlsla ? En fait, je n’en vois qu’un seul : Daniel, le développeur de mysqlsla, a annoncé au printemps que l’outil ne serait plus maintenu. La raison est simple : Daniel fait maitenant partie de l’équipe de développement de Maatkit, qui propose un outil remplaçant mysqlsla. Mais assez dit, ce sera l’objet du prochain article de cette série.

Avant toute chose, montons une petite configuration qui va nous être utile pour illustrer le fonctionnement et les limitations de chaque outil.

Prenons un serveur MySQL en version 5.1 avec la table exemple sakila et choisissons une valeur de long_query_time de 0.05s. Pourquoi une valeur aussi faible ? Tout simplement parce qu’avec une telle valeur, il n’est vraiment pas difficile des requêtes qui seront considérées comme lentes, ce qui nous permettra d’obtenir facilement un journal de requêtes lentes.

Effectuons les requêtes suivantes :

(1) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-01' GROUP BY customer_id;
(2) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-02' GROUP BY customer_id;
(3) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-03' GROUP BY customer_id;
(4) mysql> CREATE TABLE rental2 LIKE rental;
(5) mysql> INSERT INTO rental2 SELECT * FROM rental;

Toutes les requêtes, sauf (4), sont lentes (si ce n’est pas le cas pour vous, il vous suffit de baisser la valeur de long_query_time).

Le journal des requêtes lentes a maintenant l’allure suivante :

# Time: 100707 14:11:51
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.074232 Lock_time: 0.000061 Rows_sent: 599 Rows_examined: 16044
use sakila;
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;
# Time: 100707 14:12:10
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.052575 Lock_time: 0.000117 Rows_sent: 599 Rows_examined: 16044
SET timestamp=1278504730;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-02' GROUP BY customer_id;
# Time: 100707 14:12:15
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.059561 Lock_time: 0.000060 Rows_sent: 599 Rows_examined: 16044
SET timestamp=1278504735;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-03' GROUP BY customer_id;
# Time: 100707 14:12:42
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.718344 Lock_time: 0.000259 Rows_sent: 0 Rows_examined: 16044
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;


Plutôt que de montrer toutes les possibilités des outils que nous allons regarder, je vous propose de nous concentrer sur quelques questions clés que l’on se pose souvent et de voir si les outils examinés permettent de répondre à ces questions :

- Comment ne garder que les groupes de requêtes qui ont entraîné le plus long temps de réponse ?
- Comment ne garder que les groupes de requêtes qui ont le plus d’occurences ?
- Comment ne garder que les requêtes qui prennent plus de x secondes ?
- Comment ne garder que les SELECT ?

La deux premières questions demandent quelques éclaircissements : qu’est-ce qu’un groupe de requêtes et pourquoi une même requête, pas trop lente mais s’exécutant plusieurs fois, serait-elle plus intéressante à analyser qu’une requête très lente ?

Premièrement, il suffit de regarder les 4 premières requêtes du listing ci-dessus pour s’apercevoir que les requêtes sont identiques à une constante près. Un appel à EXPLAIN donnera le même résultat pour toutes les requêtes, et l’amélioration de l’une d’elles les améliorera toutes.
Et deuxièmement, il faut garder à l’esprit qu’une requête exécutée 1000 fois par seconde en 1 ms chargera plus le serveur qu’une requête exécuté 1 fois par seconde en 0.5s. La recherche des requêtes qui provoquent le plus de charge est un travail aussi important que la recherche des requêtes les plus lentes.

Nous allons regarder dans cet article mysqldumpslow, qui est un script Perl que vous trouverez dans toute distribution MySQL. Ce script est assez rustique (il a été écrit en 2000 !) mais comme c’est le seul outil d’analyse fourni en standard, nous allons y jeter un oeil.

L’utilisation est très simple : il suffit de passer le chemin du journal au script, avec éventuellement des options que nous allons examiner un peu plus loin.

Voici ce que nous obtenons dans notre cas :

$ mysqldumpslow msandbox-slow.log

Reading mysql slow query log from msandbox-slow.log
Count: 1 Time=0.72s (0s) Lock=0.00s (0s) Rows=0.0 (0), msandbox[msandbox]@localhost
insert into rental2 select * from rental

Count: 3 Time=0.06s (0s) Lock=0.00s (0s) Rows=599.0 (1797), msandbox[msandbox]@localhost
select customer_id,count(*) from rental where return_date>'S' group by customer_id


Quelques commentaires sur le rapport obtenu :

- Les requêtes sont rassemblées au sein de groupes comme nous l’avons expliqué. Les constantes qui changent entre chaque requête d’un même groupe sont remplacées par un S, ce qui indique que les valeurs réelles sont des chaines de caractères ou par un N, ce qui indique que les valeurs réelles sont des nombres. Cette présentation concise est bien pratique car très souvent vous retrouverez le même type de requêtes exécuté des dizaines ou des centaines de fois, mais elle a pour inconvénient de ne pas fournir de requête directement exploitable : si vous voulez utiliser EXPLAIN, il vous faudra d’abord remplacer le S par une ‘vraie’ valeur, ce qui peut s’avérer désagréable à l’usage. Il est possible de demander à mysqldumpslow de ne pas rendre abstraites les constantes, mais dans ce cas, chaque requête d’un groupe est considérée comme unique si bien que le regroupement est perdu.

- Les champs Time, Lock et Rows reprennent les informations du journal, en mentionnant la valeur moyenne et la valeur totale (entre parenthèses) de chaque champ pour le groupe. Notez que pour les valeurs totales de Time et Lock, l’unité est la seconde, ce qui était bien adapté en 2000 quand la résolution du journal était la seconde, mais ne l’est plus du tout dans notre cas. Ces valeurs ne sont donc pas toujours exploitables.

Pouvons-nous répondre aux questions que nous nous étions posées avec mysqldumpslow ?

Pour les 2 premières (groupe de requêtes ayant le plus d’occurences et ayant entrainé le plus long temps de réponse), la réponse est oui. mysqldumpslow dispose en effet d’une option pour trier les entrées du rapport selon différents critères. Ainsi :
mysqldumpslow -s c msandbox-slow.log
trie les groupes de requêtes par nombre d’occurences. Et

mysqldumpslow -s t msandbox-slow.log
trie les groupes de requêtes par temps d’exécution. Notez que le tri se fait sur le temps total, ie le chiffre entre parenthèses. Si vous préférez que le tri se fasse sur le temps moyen il faut utiliser l’option -s at.

Pour la troisième question, portant sur les requêtes prenant plus de x secondes, nous ne pouvons pas directement obtenir le résultat. Mais nous pouvons nous en approcher en triant par temps de réponse et en utilisant l’option -t qui n’affiche que les N premiers résultats :
mysqldumpslow -s t -t 1 msandbox-slow.log
donne le groupe de requêtes ayant le temps total d’exécution le plus long. Il suffit alors de trouver, par tâtonnements successifs par exemple, la bonne valeur de l’option -t qui va nous permettre d’obtenir le résultat voulu.

Quant à la dernière question, à savoir filtrer l’affichage sur les SELECT, il existe bien une option -g qui permet de fournir un motif de filtrage, mais il ne m’a pas semblé possible dans notre cas de trouver un motif qui filtre le INSERT … SELECT sans filtrer les SELECT.

Résumons donc : mysqldumpslow est un outil très simple, toujours disponible, qui permet de produire un rapport concis mais peu précis en regroupant les requêtes similaires. Les possibilités de filtrage sont réduites au minimum, ce qui n’en fait pas un outil très pratique quand le journal contient beaucoup d’entrées. On l’utilisera donc surtout quand aucun autre outil n’est disponible, ce qui devrait être finalement assez rare, puisque rien ne vous empêche de rapatrier le journal de requêtes lentes sur votre PC pour l’analyser avec un autre outil.

Rendez-vous très bientôt pour la seconde partie de notre découverte des outils d’analyse de journaux de requêtes lentes avec mysqlsla.

Le livre est bien sûr disponible dans toutes les bonnes librairies informatiques et autres FNAC, Amazon …

Bonne lecture !

Tout d’abord, il faut savoir que la version 5.1 a apporté pas mal de changements par rapport aux possibilités offertes jusqu’alors. Mais pour que les choses restent claires, nous allons commencer par présenter les options disponibles en 5.0.

Le but du journal des requêtes lentes, quelle que soit la version de MySQL, est de tracer l’ensemble des requêtes qui sont jugées lentes, c’est-à-dire dont le temps d’exécution est supérieur à une certaine limite. Ce qui est intéressant dans ce journal, c’est que le serveur écrit les requêtes après leur exécution, ce qui permet de disposer de pas mal d’informations intéressantes. Remarquez que c’est logique : on ne peut bien sûr pas savoir avant de l’avoir exécutée si une requête est lente ou pas …

L’activation/désactivation du journal se fait avec la variable log_slow_queries. Par défaut, celle-ci est à OFF :

mysql> SHOW VARIABLES LIKE 'log_slow_queries';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| log_slow_queries | OFF   |
+------------------+-------+


La variable ne peut pas être modifiée dynamiquement, le mieux est donc d’aller éditer le fichier my.cnf :

[mysqld]
log_slow_queries

puis de redémarrer le serveur.

Notez que si vous ne précisez aucun chemin, le journal est créé dans le répertoire de données (ce qui n’est pas idéal) et porte le nom hostname-slow.log. Le mieux est donc de préciser un chemin absolu, par exemple :

[mysqld]
log_slow_queries = /var/log/mysql/mysql-slow.log


La seconde option importante à configurer est la durée à partir de laquelle une requête est considérée comme lente. Ce réglage se fait avec la variable long_query_time, qui peut être modifiée dynamiquement :

mysql> SHOW GLOBAL VARIABLES LIKE 'long_query_time';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 10    |
+-----------------+-------+
1 row in set (0.00 sec)


mysql> SET @@global.long_query_time = 5;
Query OK, 0 rows affected (0.00 sec)


mysql> SHOW GLOBAL VARIABLES LIKE 'long_query_time';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 5     |
+-----------------+-------+
1 row in set (0.00 sec)

Munis de ces informations, nous pouvons maintenant écrire une requête lente :

mysql> SELECT SLEEP(15);


et voir ce qui se trouve dans le journal :

# Time: 100528 11:48:13
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 15 Lock_time: 0 Rows_sent: 1 Rows_examined: 0
SELECT SLEEP(15);


Les informations des 2 premières lignes (date et utilisateur) permettent, en utilisant des outils existants ou avec son propre script, de regrouper les événements pour déterminer s’il y a plus de requêtes lentes certains jours ou à certains moments de la journée, ou encore si un utilisateur provoque plus de requêtes lentes que les autres.

La 3è ligne est particulièrement intéressante puisqu’en plus du temps d’exécution de la requête, nous avons le temps perdu à cause des verrous et nous pouvons comparer le nombre de lignes renvoyées au nombre de lignes examinées. Un examen rapide de ces informations nous permet donc rapidement de savoir si la requête est lente à cause d’une contention sur les ressources (Lock_time élevé) ou si l’exécution est loin d’être optimale (Rows_examined élevé par rapport à Rows_sent).

Un exemple réel plus parlant ? En voici un :

# Time: 100401 6:30:14
# User@Host: xxx[xxx] @ backoffice.xxx [10.xxx.xxx.xxx]
# Query_time: 12.012118 Lock_time: 0.000660 Rows_sent: 0 Rows_examined: 359462


Ici, on voit tout de suite que le plan d’exécution mériterait d’être revue : le serveur lit 360 000 lignes pour en retourner … 0 !

Du côté des limitations en 5.0, 3 points sont à noter : outre le fait de ne pas pouvoir activer/désactiver le journal sans devoir redémarrer le serveur, les requêtes exécutées sur un slave par le thread de réplication ne sont jamais tracées dans le journal et la valeur de la variable long_query_time est nécessairement un entier.

Ces deux derniers points ont des conséquences gênantes :

• si vous activez le journal sur un slave mais pas sur le master, vous risquez de passer à côté de requêtes de mises à jour qui sont lentes, les mises à jour étant toutes exécutées par le thread de réplication
• si votre application est déjà bien optimisée, votre journal sera probablement vide car vous n’aurez plus aucune requête s’exécutant en plus d’une seconde : si vous souhaitez malgré tout repérer les requêtes les plus longues à exécuter, il faudra trouver un autre moyen pour les tracer

Il existe encore 2 autres options disponibles : la possibilité de tracer les requêtes « administratives » (par exemple, REPAIR TABLE) qui sont lentes ou encore la possibilité de tracer les requêtes n’utilisant pas d’index, quel que soit leur temps d’exécution. Il suffit pour cela de renseigner l’une ou l’autre des variables dans le fichier my.cnf :


[mysqld]
log-slow-admin-statements
log-queries-not-using-indexes


L’option log-queries-not-using-indexes mérite quand même qu’on s’y attarde un peu… En effet, cette option va en réalité tracer les requêtes qui parcourent toutes les lignes d’une table, peu importe si ce parcours se fait ou non avec un index. Pas très clair ? Prenons un exemple.

Voici 2 structures de table, identiques sauf que l’une a pour moteur InnoDB et l’autre MyISAM :

CREATE TABLE t1 (
id int(11) NOT NULL auto_increment,
PRIMARY KEY (id)
) ENGINE=InnoDB



CREATE TABLE t2 (
id int(11) NOT NULL auto_increment,
PRIMARY KEY (id)
) ENGINE=MyISAM

Remplissons les tables avec quelques lignes en répétant plusieurs fois les insertions suivantes :

mysql> INSERT INTO t1 (id) VALUES (NULL);
mysql> INSERT INTO t2 (id) VALUES (NULL);


Maintenant la requête suivante va se retrouver dans le journal des requêtes lentes :

mysql> SELECT COUNT(*) FROM t1;


alors que celle-ci n’y sera pas :

mysql> SELECT COUNT(*) FROM t2;


Quelle est l’explication ? Il suffit de regarder le plan d’exécution donné par EXPLAIN. Pour la table t1, EXPLAIN indique que le plan est de faire un full index scan alors que pour t2, aucune opération n’est nécessaire (donc en particulier aucun index n’est utilisé), le moteur MyISAM gardant toujours parmi ses méta-données le nombre d’enregistrements de la table.

Dans notre cas, MySQL a donc tracé la requête utilisant un index et ignoré celle n’en utilisant pas… Quand je disais que cette option méritait qu’on s’y attarde un peu !

Maintenant que nous avons fait le tour de ce qui est possible en 5.0, voyons ce que la 5.1 a apporté de neuf. C’est simple : que du bon ! Ainsi, il est désormais possible d’activer/désactiver le journal dynamiquement, de tracer les requêtes lentes dans un fichier ou dans une table, d’indiquer un seuil non plus en secondes mais en microsecondes et enfin de tracer les requêtes exécutées par le thread de réplication !

Dans le détail, c’est un peu plus compliqué…

La variable log_slow_queries a été remplacée par slow_query_log : c’est grâce à elle que vous activez/désactivez le journal.

Par défaut, le journal est écrit dans un fichier, dont vous pouvez préciser le nom avec la variable slow_query_log_file.

Pour écrire dans une table, il faut modifier la variable log_output en précisant TABLE. Vous pouvez aussi choisir d’écrire à la fois dans un fichier et dans une table avec log_output = FILE, TABLE. Attention, la variable log_output s’applique également au journal général (general log) si celui-ci est activé.

Le seuil décrit par long_query_time s’écrit toujours en secondes, mais avec une précision pouvant aller jusqu’à la microseconde. Vous pouvez donc maintenant définir un seuil de 0.05s : long_query_time = 0.05. Attention, si vous écrivez dans une table, la granularité redevient la seconde comme en 5.0 !

Une petite nouveauté aussi, vous avez la possibilité de ne tracer que les requêtes qui examinent au moins un certain nombre de lignes avec la variables min_examined_row_limit.

Enfin, dernier point, la variable log-slow-slave-statements, disponible à partir de la 5.1.45 permet de tracer les requêtes lentes exécutées par le thread de réplication.

Ca y est, vous savez tout sur le journal des requêtes lentes de MySQL ! Enfin, presque, car si vous utilisez la version de MySQL patchée par Percona, vous trouverez des informations supplémentaires. Ceci fera sans doute l’objet d’un nouvel article. En attendant, nous examinerons prochainement quels sont les outils disponibles pour analyser les requêtes lentes.

Commençons par le plus simple : que contient ce journal ? Facile : toutes les erreurs rencontrées par le serveur. Mais vous y trouverez également d’autres informations, comme par exemple les arrêts et démarrages du serveur. Par défaut, l’option log_warnings est activée (valeur à 1), ce qui signifie que les messages d’avertissement sont également présents. Si vous ne souhaitez pas avoir les message d’avertissement, il vous suffit de positionner cette variable à 0. A l’inverse, si vous voulez avoir des informations supplémentaires, telles que les problèmes réseaux, vous pouvez positionner cette variable à 2.
Pour les utilisateurs de Windows, sachez que certaines données sont reprises dans le journal des événements.

Voilà pour la partie facile. Les choses se compliquent déjà un peu plus quand on cherche à savoir où se trouve le fichier d’erreur… A priori pourtant, ce n’est pas difficile, il suffit de regarder du côté de la variable log_error. Celle-ci peut prendre 3 valeurs :

• chaîne vide (par défaut), le journal d’erreurs s’appelle alors [hostname].err et se trouve dans le répertoire de données
• un nom d’un fichier, dans ce cas, le journal se trouve dans le répertoire de données et porte le nom indiqué
• le chemin absolu d’un fichier, alors le journal se trouve à l’emplacement indiqué

Cela signifie que dans les deux premiers cas, il faut également regarder la variable datadir pour connaître l’emplacement du répertoire de données.

Deux petites remarques au passage :

• il n’est pas possible de désactiver le journal d’erreurs
• le journal est toujours écrit dans un fichier et jamais dans une table comme vous pouvez le faire pour la general log et la slow log à partir de la version 5.1

En réalité, c’est encore un peu plus compliqué. Dans certaines distributions Linux, comme Debian ou Ubuntu par exemple, le journal passe par syslog. Les événements ont alors un tag mysqld_safe ou mysqld selon leur origine. La raison en est une petite variable bien cachée dans un fichier … lui aussi bien caché : si vous regardez dans le répertoire /etc/mysql/conf.d/, vous y trouverez un fichier mysld_safe_syslog.cnf qui contient simplement la directive suivante :
[mysqld_safe]
syslog

A partir de la version 5.1, la variable syslog est disponible en standard (mais pas pour Windows bien sûr !).

Est-ce un bon choix d’utiliser cette variable syslog ? La réponse va sans doute dépendre de votre manière de surveiller les logs : si vous ne vous intéressez qu’à MySQL, devoir retrouver les événements liés à MySQL parmi tous les autres événements va être laborieux, mais au contraire, si MySQL n’est qu’une application parmi tant d’autres, il vous sera bien agréable d’avoir un journal d’erreurs dans un format standard.

Subtilité ou complication supplémentaire, vous pouvez même avoir votre journal d’erreur en double, une première fois via syslog et une deuxième fois dans le fichier d’erreur classique. Comment faire ? Il vous faut activer en même temps la variable syslog et la variable log_error :
[mysqld_safe]
syslog

[mysqld]
log_error = error.log

Quel est l’intérêt ? A vrai dire, je n’en vois pas vraiment …

Voyons maintenant quelques bonnes pratiques.

La première question à vous poser, en supposant que vous êtes sous Linux et que votre version ou votre distribution vous en donne la possibilité, est de savoir si vous souhaitez utiliser syslog ou pas.

Si oui, il vous suffit de positionner la variable syslog dans la section [mysqld_safe] du fichier my.cnf et la configuration est terminée.

Sinon, si vous laissez la variable à vide ou si vous mettez un nom de fichier, votre journal d’erreurs va se trouver dans le répertoire de données, ce qui n’est pas souhaitable. Même s’il existe peu de chances que le journal d’erreurs remplisse tout l’espace disque disponible dans le répertoire de données (c’est plus plausible avec les logs bins), il est en effet toujours mieux de ne pas mélanger les torchons et les serviettes : les données avec les données et les logs avec les logs ! De plus, vous risquez d’avoir des problèmes de droit : dans le répertoire de données, seul les utilisateurs du groupe mysql ont le droit d’accéder à ce fichier, alors que vous aurez peut-être besoin de donner des accès à d’autres utilisateurs sans pour autant leur laisser un accès aux données. Il est donc conseillé de saisir un chemin absolu vers un fichier, par exemple :
[mysqld]
log_error = /var/log/mysql/error.log

Un autre aspect à prendre en compte est celui de la rotation. En effet, si vous n’y faites pas attention, la rotation des logs risque de vous faire perdre une grande partie des informations du journal d’erreurs !
Le premier point à constater est que la rotation du journal d’erreurs ne se fait pas automatiquement au démarrage du serveur ou lorsque la taille du fichier dépasse une certaine limite. La seule possibilité consiste à exécuter la commande FLUSH LOGS (qui affecte également les autres logs).

Quand vous utilisez syslog, par défaut, votre système fait une rotation tous les jours, et les logs sont purgées après 7 jours. Sauf si vous prenez des mesures pour sauvegarder les logs après leur rotation, vous avez donc seulement le journal des erreurs des 7 derniers jours à votre disposition.

Mais quand vous utilisez un journal d’erreurs classique, la situation est beaucoup plus dangereuse ! En effet, l’appel de la commande FLUSH LOGS créé un nouveau journal d’erreurs et sauvegarde l’ancien dans un fichier avec le suffixe -old. Et si vous aviez déjà un fichier -old, celui-ci est purement et simplement supprimé !

Petite démo :
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log
-rw-rw---- 1 ... 939 2010-04-16 10:45 error.log-old

J’ai bien un journal d’erreurs ainsi qu’un journal en -old. J’exécute FLUSH LOGS pour voir l’effet :

stephane@cilaos:/var/lib/mysql$ mysql -uroot -p -e "FLUSH LOGS"
Enter password:
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 0 2010-04-16 10:47 error.log
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log-old

Et voilà, mes anciennes erreurs sont perdues à tout jamais…

Conclusion : mieux vaut sauvegarder régulièrement son journal d’erreurs car nul n’est à l’abri d’un FLUSH LOGS non prévu.

Notre exploration du journal d’erreurs est terminée, et nous reviendrons bientôt sur un autre journal extrêmement important : le journal des requêtes lentes.

Les keynotes:

• State of the Dolphin Edward Screven (Oracle Corporation)
• O’Reilly Radar Tim O’Reilly (O’Reilly Media, Inc.)
• MySQL at Facebook Mark Callaghan (Facebook)

Les sessions:

• MySQL in the Cloud – Endless Possibilities Grant McAlister (Amazon.com)
• Parallel MySQL Import and Export to Hadoop Aaron Kimball (Cloudera)
• Nokia VShards in the Cloud: Voldemort Key-Value Database With MySQL High Performance Persistent Store (Alex Esterkin)
• Introduction to InnoDB Monitoring System and Resource & Performance Tuning ( Jimmy Yang)
• Optimizing MySQL Stored Routines Roland Bouman (XCDSQL Solutions)
• Linux Performance Tuning and Stabilization Tips (Yoshinori)

Je reviendrai plus en details sur ces sessions par la suite.

• 2007: la decouverte, l aventure MySQL
• 2008: SUN achete MySQL
• 2009: Oracle annonce le rachat de SUN et donc de MySQL, l’ogre a mange le petit?
• 2010: La premiere conference sous l ere Oracle.

Je ne sais pas encore quel va etre mon programme de la semaine, mais le lundi je vais suivre « MySQL Cluster Tutorial »… il serait temps
Comme d’habitude depuis 2007, DBNewz sera present pour vous faire suivre les actualites de la conference. Restez branches !

Vous trouverez ici-même le sommaire et l’avant-propos. Le premier chapitre (« Gérer une situation d’urgence avec MySQL »), est disponible sur le blog d’Olivier.

Le livre sort ce jeudi en librairie, fnac.com, eyrolles.com, amazon.fr…

Bonne lecture !

MySQL 5 Audit et optimisation

La rédaction de l’ouvrage étant maintenant dernière nous, les billets vont pouvoir reprendre à une allure plus digne de ce blog ! Je tiens d’ailleurs à remercier Stéphane qui a enrichi le site pendant que Pascal et moi étions à 100% sur le livre : l’intérêt de blogger en équipe…

La date officielle de sortie est le 25 mars. D’ici là voici le pdf du communiqué de presse concernant l’ouvrage. Celui-ci était présent en quantité limitée lors du dernier salon Solutions Linux.

Il est d’ores et déjà disponible en précommande.

Nous posterons ici même d’ici peu quelques morceaux choisis en pdf issus du livre dès que nous les aurons reçus de notre éditeur, c’est imminent.

Quand vous ouvrez une console, le prompt est par défaut :

mysql>


Pour le modifier, une première possibilité consiste à utiliser la commande prompt (ou son équivalent \R) suivie d’une ou plusieurs options. Exemple :

mysql> prompt \u\h
PROMPT set to '\u\h'
rootlocalhost

Ce premier exemple permet d’indiquer l’utilisateur connecté ainsi que la machine. C’est déjà intéressant, mais pas très lisible, puisque tout est collé. Heureusement vous pouvez ajouter n’importe quels caractères pour séparer les différents champs du prompt. Il sera donc plus lisible de saisir le prompt suivant :

rootlocalhostprompt \u@\h>
PROMPT set to '\u@\h> '
root@localhost>

Notez l’espace après le >, bien pratique pour séparer le prompt des commandes que vous allez saisir.
Parmi les options très utiles du prompt, en plus de \u et \h, vous avez \v (version du serveur) et \d (base sélectionnée). Les options disponibles sont nombreuses et si vous souhaitez en avoir la liste complète, le mieux est de regarder dans la page de man consacrée à mysql ou de consulter la documentation en ligne.

Est-il possible de faire en sorte qu’une telle modification du prompt soit permanente ? Oui ! Et pour cela, il existe plusieurs solutions. La première consiste à enregistrer le prompt dans la variable MYSQL_PS1 :

$ export MYSQL_PS1="\u@\h \d > "
$ mysql -uroot -p
root@localhost (none) >


La seconde solution consiste à saisir le prompt dans la section [mysql] du fichier my.cnf ou my.ini. Dans ce cas, vous devrez penser à doubler les backslash :

[mysql]
prompt = "\\u@\\h \\d > "

Si vous êtes sous Linux, vous pouvez également placer ce même code dans le fichier .my.cnf (dans le HOME de votre utilisateur). Cette solution est intéressante car elle permet d’obtenir le résultat voulu sans avoir à modifier le fichier global my.cnf, pour lequel vous n’aurez pas nécessairement les droits de modification.

Notez que si vous êtes un utilisateur de MySQL Sandbox, le prompt sera automatiquement et intelligemment modifié pour que vous ne soyez pas perdu parmi toutes vos instances. Par exemple, j’obtiens le prompt suivant en me connectant sur un des nœuds d’une paire master-master :

$ ./n1
node1 [localhost] {msandbox} ((none)) >


Maintenant, vous n’aurez plus d’excuse si vous vous trompez de console … !