Une de mes tables a une tendance marquée à la fragmentation, ce qui a pour conséquence de faire gonfler artificiellement sa taille et de faire baisser les performances de certaines requêtes. Je dois donc de temps à autre la défragmenter. Pas de problème : je commence par regarder la taille sur le disque du fichier .ibd (il s’agit d’une table InnoDB sur un serveur pour lequel innodb_file_per_table est activé). Quand la table est défragmentée, elle fait environ 8 Go :

# cd /data/mysql/main_revshare
# du -sh bris_statistic_video.ibd
11G bris_statistic_video.ibd

Pas de doute, une séance de défragmentation s’impose. Je me connecte donc au serveur MySQL pour exécuter un OPTIMIZE TABLE :

mysql> OPTIMIZE TABLE bris_statistic_video\G
******** 1. row ********
Table: dailymotion.bris_statistic_video
Op: optimize
Msg_type: Error
Msg_text: Table 'dailymotion.bris_statistic_video' doesn't exist
******** 2. row ********
Table: dailymotion.bris_statistic_video
Op: optimize
Msg_type: error
Msg_text: Corrupt

Et là, c’est le drame ! Quoi, ma table est corrompue ? Impossible, l’application fonctionne toujours et la table est utilisée partout !

Comment sortir de ce problème : redémarrer le serveur en espérant qu’InnoDB répare la table, récupérer un backup ? En fait non, il faut simplement rester calme et bien regarder le message : si à la 2ème ligne, MySQL nous annonce que la table est corrompue, à la 1ère MySQL nous annonce que la table n’existe pas … alors que nous avons vu que le fichier .ibd existe bien. Louche cette histoire !

Un tour dans le journal d’erreurs confirme bien qu’il n’existe aucune erreur : il doit donc y avoir une erreur avec la commande OPTIMIZE. Réfléchissons, réfléchissons … ça y est : j’ai exécuté la commande OPTIMIZE dans la base main alors que ma table se trouve dans la base main_revshare. Il suffit donc de se positionner dans main_revshare et de relancer l’OPTIMIZE, avec succès cette fois.

Moralité : Mieux vaut se méfier des messages d’erreurs qui ne vous sont pas familiers et bien réfléchir à la cause de l’erreur avant de se lancer dans la correction d’un problème qui n’existe peut-être pas !

Idée générale

Si vous avez bien lu l’article précédent, vous avez probablement remarqué que la principale difficulté est qu’il n’existe quasiment jamais de règle absolue permettant de savoir à coup sûr qu’un index est inutile (exception notable : les index en doublon repérés par mk-duplicate-key-checker et qui peuvent être supprimés dans 99% des cas sans problème). Finalement, la seule méthode qui semble marcher est la suivante :
- Récupérer les requêtes exécutées sur le serveur
- Regarder le plan d’exécution de ces requêtes pour voir les index utilisés
- Comparer avec le schéma des tables pour en déduire les index non utilisés
- Supprimer les index repérés
La difficulté se situe surtout dans la 2ème étape (construire la liste des index utilisés à partir du plan d’exécution). Heureusement il existe au moins 2 manières, en fonction de votre version de MySQL, pour réussir cette étape.

Index_statistics

Les heureux utilisateurs de MariaDB ou Percona Server ont la chance d’avoir userstats v2, un patch exceptionnel développé à l’origine par Google. Ce patch ajoute un nombre incalculable de statistiques sur les utilisateurs, les tables mais aussi, ce qui nous intéresse ici, les index. Pour activer la fonctionnalité, il suffit de changer une variable :
mysql> SET GLOBAL userstat_running = 1;

A partir de ce moment, la table INDEX_STATISTICS de la base INFORMATION_SCHEMA va se remplir. Les colonnes sont très simples à comprendre : TABLE_SCHEMA, TABLE_NAME et INDEX_NAME localisent l’index et ROWS_READ donne le nombre de lignes lues dans l’index. Evidemment, pour obtenir des statistiques significatives et fiables, il faut attendre suffisamment longtemps avant de consulter le contenu de la table. Une bonne question est de savoir ce que signifie « suffisamment longtemps » : disons qu’il faut que chaque requête potentielle de l’application ait pu être exécutée, en pensant bien aux requêtes rares telles que les requêtes faites dans des cronjobs par exemple.

Un petit exemple sur des données réelles ?

mysql> SELECT * FROM INFORMATION_SCHEMA.INDEX_STATISTICS WHERE TABLE_NAME='main';
+--------------+------------+------------+-----------+
| TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | ROWS_READ |
+--------------+------------+------------+-----------+
| biz          | main       | user_id    | 231751890 |
| biz          | main       | created    | 4456658   |
| biz          | main       | PRIMARY    | 1748023896 |
| biz          | main       | modified_idx    | 266636148 |
| biz          | main       | mobile_idx    | 550 |
+--------------+------------+---------------+------------+

et voyons en parallèle le schéma de la table :

mysql> SHOW CREATE TABLE main\G
********* 1. row *********
Table: main
Create Table: CREATE TABLE main (
  ...
  PRIMARY KEY (main_id),
  KEY user_id (user_id),
  KEY created (created),
  KEY language_idx (language),
  KEY mobile_idx (mobile,deleted,web,published),
  KEY country_mobile_idx (country,mobile),
  KEY modified_idx (modified)
) ENGINE=InnoDB;

Qu’en déduit-on ? En premier lieu, que les index language_idx et country_mobile_idx ne sont jamais utilisés, ils ne servent donc à rien et peuvent être supprimés. Ensuite, en comparant les chiffres, on voit que le serveur a lu 1,7 milliards de lignes dans la clé primaire, 550 dans l’index mobile_idx : aucun doute mobile_idx ne sert à rien lui non plus !

Et voilà, de manière très simple, nous avons trouvé des index qui peuvent être supprimés.
On peut même automatiser la découverte des index non utilisée avec une petite requête qui va bien.

Quelles sont les limitations de cette méthode ? Très simple, autant les index qui ne sont jamais utilisés sont visibles immédiatement, autant on peut se poser la question de la pertinence de certains index. Et malheureusement, les chiffres donnés par la table INDEX_STATISTICS ne sont pas suffisants. Exemple : l’index created affiche un nombre de lignes lues environ 500 fois plus faibles que la clé primaire : cela signifie-t-il qu’il n’est pas très utile ou qu’au contraire il est très utile mais seulement sur certaines requêtes ?

mk-index-usage

Quand on ne dispose de userstats, la seule solution consiste à collecter toutes les requêtes pendant une période suffisamment longue, par exemple en mettant long_query_time à 0 pour que toutes les requêtes aboutissent dans le slow query log, et à se tourner vers Maatkit en espérant y trouver notre bonheur. Ca tombe bien, mk-index-usage est justement un outil lisant un fichier de log et délivrant de nombreuses informations intéressantes (en déterminant en particulier le plan d’exécution des requêtes).

Par défaut, mk-index-usage prend en entrée un fichier de log au format slow query log et affiche une liste de requêtes SQL pour supprimer les index inutiles :

$ mk-index-usage slow.log
slow.log: 5% 08:28 remain
slow.log: 11% 07:20 remain
slow.log: 14% 08:36 remain
...
slow.log: 93% 00:37 remain
slow.log: 97% 00:12 remain

ALTER TABLE `main`.`adfit` DROP KEY `status`; — type:non-unique
…
ALTER TABLE `main`.`biz` DROP KEY `created`, DROP KEY `modified_idx`; — type:non-unique

Surprise ! Le script a bien identifié modified_idx comme inutile, mais pas mobile_idx. Et il a décidé que created pouvait être supprimé alors que nous avons vu que ce n'était pas forcément évident.

Comme d'habitude avec Maatkit, si vous êtes curieux et que vous lisez la documentation, vous verrez qu'il existe une multitude d'options permettant d'obtenir bien plus d'informations sur l'usage des index sur votre plate-forme. De plus, cette méthode est compatible avec toutes les versions de MySQL

Conclusion

Les deux méthodes présentées ici peuvent vous faire gagner beaucoup de temps en vous aidant à identifier les index candidats à la suppression. Bien entendu, comme souvent, il ne serait pas très prudent de faire confiance aveuglément à un script pour gérer votre plate-forme : votre travail consistera à vérifier s'il faut effectivement enlever les index qui sont susceptibles d'être supprimés. Normalement, ce type d'index ne devrait représenter qu'une petite portion des index de votre application, le gain de temps sera donc appréciable.

Index en doublon

Les index en doublon sont simplement ceux qui sont définis plusieurs fois. Un exemple simple pour commencer :
CREATE TABLE t (
  id int(11) DEFAULT NULL,
  KEY a (id),
  KEY b (id)
);

Notons que MySQL n’empêche en aucun cas ce genre de définition erronée.

Un autre exemple, un peu plus compliqué :
CREATE TABLE u (
  id int(11) NOT NULL DEFAULT '0',
  UNIQUE KEY (id),
  KEY b (id)
);

La logique était : je crée une contrainte d’unicité sur la colonne id, puis un index pour accélérer les requêtes. Sauf qu’avec MySQL, toutes les contraintes sont vérifiées avec des index, ce qui signifie que la création de la contrainte d’unicité crée implicitement un index (idem pour PRIMARY KEY et FOREIGN KEY).

Un dernier exemple :
CREATE TABLE v (
  id int(11) NOT NULL DEFAULT '0',
  col varchar(10) DEFAULT NULL,
  PRIMARY KEY (id),
  KEY a (col),
  FULLTEXT KEY b (col)
) ENGINE=MyISAM;

Ici, nous avons bien deux index sur col, mais ce ne sont pas des index de même type, ils ne sont donc pas en doublon. Attention aux excès de zèle !

Les index en doublon n’apportent rien, il est donc toujours utile de pouvoir les repérer pour ensuite les supprimer. Un bon outil pour ce travail est mk-duplicate-key-checker de Maatkit. L’outil est très simple d’usage et la documentation complète.

Par exemple, pour vérifier si notre table u (dans la base test) contient des index en doublon, on peut utiliser la ligne suivante :
$ mk-duplicate-key-checker h=localhost,u=root,D=test -t u
# ##################################
# test.u
# ##################################

# b is a duplicate of PRIMARY
# Key definitions:
# KEY `b` (`id`)
# PRIMARY KEY (`id`),
# Column types:
# `id` int(11) not null default '0'
# To remove this duplicate index, execute:
ALTER TABLE `test`.`u` DROP INDEX `b`;

# ##################################
# Summary of indexes
# ##################################

# Size Duplicate Indexes 0
# Total Duplicate Indexes 1
# Total Indexes 2

L’outil suggère avec raison que l’index b est en doublon de la clé primaire et propose sous la forme d’un ALTER TABLE une requête pour supprimer cet index.

La même ligne de commande, en version longue :
$ mk-duplicate-key-checker --host localhost --user root --databases test --tables t

Il est bien sûr possible d’examiner en une seule passe toutes les tables de la base test :
$ mk-duplicate-key-checker --host localhost --user root --databases test
# ##################################
# test.t
# ##################################

# a is a duplicate of b
# Key definitions:
# KEY `a` (`id`),
# KEY `b` (`id`)
# Column types:
# `id` int(11) default null
# To remove this duplicate index, execute:
ALTER TABLE `test`.`t` DROP INDEX `a`;

# ##################################
# test.u
# ##################################

# b is a duplicate of id
# Key definitions:
# KEY `b` (`id`)
# UNIQUE KEY `id` (`id`),
# Column types:
# `id` int(11) not null default '0'
# To remove this duplicate index, execute:
ALTER TABLE `test`.`u` DROP INDEX `b`;

# ##################################
# Summary of indexes
# ##################################

# Size Duplicate Indexes 0
# Total Duplicate Indexes 2
# Total Indexes 7

Parfait, mk-duplicate-key-checker a bien identifié les doublons et ne s’est pas fait piéger par l’index FULLTEXT de la table v.

Index redondants

Pour les index de type BTREE (c’est-à-dire tous les index sauf les index HASH de Memory et les index FULLTEXT de MyISAM), l’optimiseur de requêtes de MySQL est capable d’utiliser un préfixe gauche d’un index composite. Tous les index portant sur des préfixes gauche d’un index composite ne sont donc théoriquement pas utiles.

Pas clair ? Regardez la table suivante :
CREATE TABLE w (
  id int(11) NOT NULL DEFAULT '0',
  col varchar(10) DEFAULT NULL,
  col2 varchar(10) DEFAULT NULL,
  KEY id (id),
  KEY id_col (id,col)
);

Et considérez la requête suivante :
SELECT * FROM w WHERE id = 1

EXPLAIN nous indique que l’index sur id est utilisé :
mysql> EXPLAIN SELECT * FROM w WHERE id = 1\G
********* 1. row ********
   id: 1
   select_type: SIMPLE
   table: w
   type: ref
   possible_keys: id,id_col
   key: id
   key_len: 4
   ref: const
   rows: 1
   Extra:

Mais si on demande à l’optimiseur de ne pas considérer l’index sur id, on voit que la requête va s’exécuter de manière aussi efficace en utilisant l’index sur (id,col) :

mysql> EXPLAIN SELECT * FROM w IGNORE INDEX(id) WHERE id = 1\G
******** 1. row ********
   id: 1
   select_type: SIMPLE
   table: w
   type: ref
   possible_keys: id_col
   key: id_col
   key_len: 4
   ref: const
   rows: 1
   Extra:

On peut donc éliminer sans problème l’index sur id.

Faut-il donc systématiquement supprimer les index redondants ? Eh bien non, il convient d’apporter quelques nuances. Disons que la majeure partie du temps, un index redondant est inutile et peut être supprimé, mais qu’il existe des situations où il faudra conserver tous les index.

Par exemple, ce sera souvent le cas quand les colonnes indexées sont de grande taille (que ceux qui n’utilisent jamais de VARCHAR(255) lèvent la main ). Pour avoir un cas concret de ce type de situation, vous pouvez lire cet article.

Comment savoir si un index redondant est utile ou non ? La seule solution utilisable est bien souvent de faire des tests.

Que dit mk-duplicate-key-checker sur les index redondants ?

$ mk-duplicate-key-checker h=localhost,u=root,D=test -t w
# ##################################
# test.w
# ##################################

# id is a left-prefix of id_col
# Key definitions:
# KEY `id` (`id`),
# KEY `id_col` (`id`,`col`)
# Column types:
# `id` int(11) not null default '0'
# `col` varchar(10) default null
# To remove this duplicate index, execute:
ALTER TABLE `test`.`w` DROP INDEX `id`;

# ##################################
# Summary of indexes
# ##################################

# Size Duplicate Indexes 16
# Total Duplicate Indexes 1
# Total Indexes 2

L’outil considère toujours les index redondants comme candidats à la suppression. A vous de voir s’il vaux mieux le conserver ou non.

Index à faible cardinalité

Arnaud a déjà parlé en détail de la notion de cardinalité d’un index. En résumé, la cardinalité est le nombre de valeurs uniques de l’index. Plus elle est élevée, plus l’index sera efficace dans son filtrage.

Si la cardinalité est faible, l’index perd de son intérêt. D’ailleurs, l’optimiseur de requêtes n’utilisera pas l’index s’il estime qu’il n’est pas utile. Voici donc de bons candidats à la suppression ! Cependant là encore, il convient de nuancer.

Imaginez un site de e-commerce avec une table contenant les commandes. Cette table va contenir un champ indiquant le statut des commandes, avec par exemple les valeurs ‘archivée’ et ‘en cours’. Au bout de quelque temps, il est certain que presque toutes les lignes de la table auront le statut ‘archivée’. Cependant, si vous écrivez une requête qui porte sur les commandes ‘en cours’, un index sur la colonne statut sera sûrement utile, même si sa cardinalité sera ridicule (2 en l’occurence).

Ce qui joue ici n’est pas seulement la cardinalité de l’index, mais aussi la distribution des valeurs et surtout les requêtes que vous faites. Si avec la même table des commandes, votre voisin ne s’intéresse qu’aux commandes archivées, l’index n’a plus aucun intérêt. C’est d’ailleurs une situation que l’on rencontre fréquemment : les requêtes que l’on peut faire en mode transactionnel ou en mode décisionnel sont radicalement différentes, exigeant souvent d’avoir des installations dédiées avec une indexation différente.

Conclusion

Cet article a montré que le repérage des index inutiles est loin d’être évident. Mis à part les index en doublon qu’on peut repérer et éliminer facilement, il est nécessaire d’avoir une bonne connaissance des requêtes qui sont exécutées afin de déterminer si un index est inutile. Le prochain article va se concentrer sur des méthodes plus systématiques d’identification des index inutiles.

Rappelons aussi que pour améliorer les performances en écriture dans l’absolu, il existe d’autres pistes que nous n’explorerons pas dans cet article :

• si la table utilise InnoDB ou XtraDB, modifier certaines variables de configuration (innodb_log_file_size,innodb_flush_log_at_trx_commit,
  innodb_adaptive_flushing, etc)
• si la table utilise MyISAM, modifier d’autres variables de configuration (myisam_sort_buffer_size, bulk_insert_buffer_size)
• faire des insertions multithreadées
• désactiver les vérifications de clés étrangères ou de clés uniques
• …

Pour commencer nos test, examinons le comportement de MyISAM. Le paramètre clé est la taille du cache d’index (key_buffer_size), nous faisons donc un essai avec un cache d’index suffisamment grand pour pouvoir contenir tous les index et un essai avec un cache trop petit.

MyISAM, key_buffer_size grand :
Seulement la clé primaire : 4s
Clé primaire + index sur col_a : 6,6s
Clé primaire + index sur col_b : 9,3s
Clé primaire + index sur (col_a,col_b) : 6,8s

MyISAM, key_buffer_size petit :
Seulement la clé primaire : 4s
Clé primaire + index sur col_a : 6,8s
Clé primaire + index sur col_b : 9,3s
Clé primaire + index sur (col_a,col_b) : 6,8s

A comparer avec les résultats obtenus la dernière fois avec InnoDB :
Seulement la clé primaire : 15s
Clé primaire + index sur col_a : 28,5s
Clé primaire + index sur col_a + index sur col_b : 44,5s
Clé primaire + index sur (col_a,col_b) : 36,3s

Très intéressant ! MyISAM se révèle plus performant qu’InnoDB, et de loin.

Attention, ne faisons pas de généralités sur la vitesse de MyISAM ! Ce test se déroule sur un serveur hors production qui n’exécute que les LOAD DATA INFILE. Il est certain que l’écart entre InnoDB et MyISAM ne serait pas aussi important si les insertions étaient multithreadées (verrouillage de toute la table pour MyISAM) et si le serveur recevait également des requêtes en lecture (les écritures seraient peut-être rapides mais les lectures souffriraient sans doute).

De plus, on voit que la taille du cache d’index n’influence quasiment pas le temps de chargement, ce qui est plutôt inattendu. Une explication possible serait que les données et index ne soient pas réellement écrits sur le disque, mais restent dans le cache de l’OS. L’hypothèse semble raisonnable puisqu’un coup d’oeil sur iostat pendant les LOAD DATA INFILE montre que les écritures sur le disque sont nettement plus nombreuses quand la table est en InnoDB.

Faisons donc un autre test avec MyISAM, pour lequel le cache d’index est petit et la quantité de mémoire disponible pour l’OS est trop faible pour pouvoir contenir les données et les index :
Seulement la clé primaire : 6,8s
Clé primaire + index sur col_a : 14s
Clé primaire + index sur col_b : 24s
Clé primaire + index sur (col_a,col_b) : 18s

Les performances sont bien moins bonnes qu’avant, mais restent encore supérieures à celles d’InnoDB !

Concentrons nous maintenant sur InnoDB et voyons l’influence du type de clé primaire sur le temps de chargement. Pour simplifier, mettons-nous toujours dans le cas où le buffer_pool est suffisamment grand pour contenir données et index.

Dans un premier temps, optons pour une clé primaire composite (id,col_c) :
Seulement la clé primaire : 17,8s
Clé primaire + index sur col_a : 40s
Clé primaire + index sur col_b : 72s
Clé primaire + index sur (col_a,col_b) : 51,7s

On voit qu’avoir une clé primaire composite a un impact non négligeable lorsqu’il n’existe pas d’autres index (20% de perte de performance) et que cet impact négatif est encore plus important quand on ajoute des index. Ce résultat était attendu, puisqu’avec InnoDB, chaque index secondaire contient la clé primaire : plus la clé primaire est volumineuse, plus les index secondaires sont volumineux et longs à mettre à jour.

Dans un second temps, supprimons la clé primaire :
Seulement la clé primaire : 14,6s
Clé primaire + index sur col_a : 29,2s
Clé primaire + index sur col_b : 45,5s
Clé primaire + index sur (col_a,col_b) : 38,1s

Les temps obtenus sont proches du cas initial où id est la clé primaire. Comment expliquer ce résultat ? InnoDB a besoin d’une clé primaire pour toutes ses tables. Si vous ne la définissez pas vous-même et qu’il n’existe pas d’index unique n’ayant aucune valeur NULL, InnoDB créé une clé primaire cachée sous la forme d’un entier. On se retrouve donc avec une structure du type suivant :

CREATE TABLE (
  hidden_id int NOT NULL AUTO_INCREMENT,
  id int(11) NOT NULL,
  col_a varchar(30) NOT NULL DEFAULT '',
  col_b varchar(30) NOT NULL DEFAULT '',
  col_c varchar(30) NOT NULL DEFAULT '',
  PRIMARY KEY (hidden_id)
);

On se retrouve avec la même structure qu’initialement, mais avec une colonne de plus, donc avec une volumétrie un peu plus importante, ce qui explique les résultats similaires mais légèrement inférieurs.

Que pouvons-nous conclure de tous ces test ? Tout d’abord, que le moteur de stockage a une grande influence sur les résultats. Si vous avez le choix du moteur, des tests s’imposent pour déterminer lequel est le meilleur, en ayant soin de prendre en compte la charge réelle de l’application (connexions concurrentes, lectures et écritures). Ensuite, que pour InnoDB, le choix de la clé primaire est critique : la clé primaire doit être la plus compacte possible, sous peine de performances très dégradées. Enfin, que pour MyISAM comme pour InnoDB, il vaut mieux limiter le nombre d’index qui ralentissent considérablement toutes les écritures.

L’application en question dispose d’une table user permettant (surprise !!) de stocker les informations sur les utilisateurs. Cette table contient environ 30 millions de lignes et a l’allure suivante :


CREATE TABLE user (
  user_id int(11) NOT NULL AUTO_INCREMENT,
  login varchar(30) NOT NULL DEFAULT '',
  name varchar(50) NOT NULL DEFAULT '',
  col_a varchar(30) NOT NULL DEFAULT '',
  col_b varchar(30) NOT NULL DEFAULT '',
  col_c varchar(30) NOT NULL DEFAULT '',
  PRIMARY KEY (user_id),
  UNIQUE KEY login (login)
) ENGINE=InnoDB;

Notons que la base ne tient pas en mémoire.

Un rapport quotidien basé sur mysqldumpslow envoyait les requêtes lentes de l’application. Parmi ces requêtes, on en trouvait une très étrange, prenant plus de 30s :

Count: 195 Time=33.05s (6445s) Lock=0.00s (0s) Rows=129903.9 (25331256), user[db]@81hosts
SELECT user_id FROM user WHERE login = N


Pourquoi est-il étrange que cette requête soit aussi lente ? Tout simplement parce qu’il existe un index sur la colonne login et que la table étant en InnoDB, on peut profiter de l’index cluster pour couvrir la requête avec l’index login. Si la dernière phrase ne vous a paru très claire, regardez donc cet article et celui-là également.

On peut confirmer facilement la validité de notre hypothèse sur le plan d’exécution avec EXPLAIN en prenant un login au hasard :

mysql> EXPLAIN SELECT user_id FROM test.user WHERE login="aqkme123456"\G
***** 1. row *****
   id: 1
   select_type: SIMPLE
   table: user
   type: const
   possible_keys: login
   key: login
   key_len: 32
   ref: const
   rows: 1
   Extra: Using index


Alors certes, la base ne tenant pas en mémoire, on ne sait pas si l’index login est en mémoire ou pas, mais dans la mesure où on accède directement à la bonne ligne, il n’y a vraiment aucune raison pour que la requête prenne plus de 30 secondes. Et en effet, les différents essais que j’ai pu faire avec des vraies valeurs donnent toujours un résultat instantané.

Poussons donc la réflexion : le problème de mysqldumpslow, c’est que l’outil ne donne qu’un exemple avec des valeurs abstraites. Il nous faudrait ici un exemple avec une valeur qui a provoqué une requête de 30s. Un autre outil permettrait-il d’avoir un tel exemple ? Oui, avec mk-query-digest de Maatkit par exemple.

Installons donc mk-query-digest, demandons lui de générer un rapport sur les logs de la veille, et regardons l’exemple réel donné par l’outil :


SELECT user_id FROM user WHERE login = 123456


Et voilà, soudainement tout est devenu limpide !! Non ? Mais si, regardez bien, la condition WHERE porte sur la colonne login de type VARCHAR et on passe un entier ! Ce qui change tout car MySQL convertit login en entier, ce qui empêche l’utilisation de l’index (rappelez-vous, MySQL ne connaît pas les function-based index) et conduit donc à un parcours complet de la table.

En réalité, cette analyse n’est pas tout à fait exacte car l’index sur login est couvrant pour la requête : il est donc possible de faire un parcours complet de la table non pas en parcourant la clé primaire mais en parcourant l’index sur login. Quelle stratégie préfère choisir MySQL ?

mysql> EXPLAIN SELECT user_id FROM test.user WHERE login=123456\G
***** 1. row *****
   id: 1
   select_type: SIMPLE
   table: user
   type: index
   possible_keys: login
   key: login
   key_len: 32
   ref: NULL
   rows: 33153173
   Extra: Using where; Using index


MySQL choisit d’utiliser l’index sur login. Etait-ce la meilleure idée, autrement dit, était-il plus rapide de scanner la table avec l’index sur login (ce qui conduit à de nombreuses lectures aléatoires) plutôt que de scanner la table séquentiellement ? Pour y répondre, le seul moyen est de faire un test avec les 2 méthodes, en utilisant le modificateur IGNORE INDEX(login) dans le second cas pour forcer le scan de la table. Et dans ce cas, les tests montrent que le scan avec l’index sur login est plus rapide.

Dernier point, qui montre à la fois que MySQL convertit bien le champ login en entier et que la requête est complètement erronée : si je joue la requête SELECT user_id FROM user WHERE login = 123456 sur mes données de production, j’obtiens non pas un résultat mais plus de 2000 ! Pourquoi un tel résultat alors que le login est censé être unique ? Tout simplement parce qu’en convertissant le champ login en entier, on perd de l’information : toutes les chaînes de caractères commençant par « 123456″ seront converties vers l’entier 123456 :

mysql> SELECT CONVERT("123456toto",UNSIGNED);
+--------------------------------+
| CONVERT("123456toto",UNSIGNED) |
+--------------------------------+
| 123456 |
+--------------------------------+


mysql> SHOW WARNINGS;
+---------+------+-------------------------------------------------+
| Level | Code | Message |
+---------+------+-------------------------------------------------+
| Warning | 1292 | Truncated incorrect INTEGER value: '123456toto' |
+---------+------+-------------------------------------------------+


La correction du problème a finalement été très simple : il a suffi au développeur de forcer l’ajout des quotes dans la requête.

Morale de l’histoire : utiliser de bons outils peut vous faire gagner un temps précieux ! Notez que si j’avais été très méticuleux, j’aurais pu arriver au même résultat avec mysqldumpslow, puisque la ligne qui m’était indiquée donnait WHERE login = N, où N représente la valeur abstraite d’un entier alors qu’il aurait fallu avoir WHERE login = S, S représentant une chaîne. Mais c’était plus facile avec mk-query-digest, non ?

16- a : Le nom d’hôte n’étant pas spécifié, ce sera donc localhost. Et pour MySQL, cela indique que le client cherche à se connecter à travers une socket : le numéro de port est ignoré. Pour que le port soit pris en compte, il faut ajouter soit -h=127.0.0.1 soit –protocol=tcp

17- b : Conséquence : quand MySQL a besoin de créer une table temporaire de manière interne (pour un tri par exemple) et que la table contient un champ TEXT ou dérivé, elle est automatiquement créée sur disque et risque de poser des problèmes de performance

18- b : Et malheureusement, la taille du tablespace ne diminue pas !

19- a : Seuls les index des tables MyISAM peuvent être mis en cache par le serveur, les données ne peuvent l’être que par l’OS, ce qui est beaucoup moins efficace

20- b : Toutes les requêtes ne peuvent pas utiliser de requêtes préparées (ex : SELECT avec un LIMIT dynamique)

21- a : Cette option démarre une transaction et fait le dump à l’intérieur de cette transaction

22- b : On trouve également cette possibilité dans le Percona Server (http://www.percona.com/docs/wiki/percona-server:features:innodb_split_buf_pool_mutex)

23- c : Avec InnoDB, la clé primaire se retrouve automatiquement dans tout index secondaire, d’où l’intérêt aussi d’avoir une clé primaire aussi compacte que possible

24- b : InnoDB stocke les données avec la clé primaire, scanner les données revient donc à scanner la clé primaire

25- c : En particulier, si le tri se fait dans une table temporaire, vous verrez alors également la mention Using temporary

26- a :

27- b :

28- c : Avec MySQL 5.5 et la fonctionnalité de réplication semi-synchrone, on peut faire en sorte qu’un ou plusieurs esclaves n’aient jamais de retard sur le maître

29- b :

30- b : Données et index peuvent être fragmentées

Comme dans tout bon quiz, c’est le moment de faire un petit bilan :

Si vous avez moins de 10 bonnes réponses sur 30 : apparemment, ce n’était pas un bon jour pour vous. Allez, soyez persévérant, tout le monde a des choses à apprendre !

Si vous avez entre 10 et 20 bonnes réponses : manifestement, vous connaissez bien les bases de MySQL, mais il vous reste encore à vous frotter aux sujets complexes pour acquérir une bonne maîtrise du sujet.

Si vous avez entre 20 et 25 bonnes réponses : votre expérience et vos connaissances vous permettent de répondre à la plupart des problèmes que vous pourrez rencontrer avec MySQL. Encore un peu de patience et de travail et vous deviendrez un véritable expert.

Si vous avez plus de 25 bonnes réponses : MySQL n’a plus beaucoup de secrets pour vous. Bravo !

Alors, quel est votre score ?

16- Sur un serveur Linux, deux instances de MySQL sont installées, l’une sur le port 3306 et l’autre sur le port 3307. Avec la commande mysql -uroot -p -P3307, sur quelle instance se connecte-t-on ?

a) L’instance écoutant sur le port 3306
b) L’instance écoutant sur le port 3307

17- Pour une table MEMORY, quelle est l’affirmation suivante qui est vraie ?

a) Les tables ne peuvent pas contenir plus d’un million de lignes
b) Les colonnes de type TEXT et dérivées ne sont pas autorisées
c) Les données ne peuvent pas être répliquées vers un serveur esclave

18- L’option innodb_file_per_table étant désactivée, quand on supprime une table InnoDB :

a) L’espace disque occupé par la table est libéré et récupéré par le système d’exploitation
b) L’espace disque occupé par la table est libéré et récupéré par le tablespace principal InnoDB
c) L’espace disque occupé par la table est conservé tant qu’un COMMIT n’a pas été exécuté

19- Quelle est la directive qui permet de spécifier la quantité de mémoire à allouer pour que les données des tables MyISAM soient mises en cache par le serveur MySQL ?

a) Il n’existe pas de telle directive
b) key_buffer_size
c) innodb_buffer_pool

20- L’utilisation des requêtes préparées permet d’éliminer tout risque d’injection SQL.

a) Vrai
b) Faux

21- Quelle est la meilleure option de mysqldump à utiliser pour réaliser une sauvegarde à chaud d’une base InnoDB ?

a) –single-transaction
b) –master-data
c) –lock-all-tables

22- MySQL 5.5 offre la possibilité d’avoir plusieurs buffer pools pour InnoDB. Quel est l’intérêt ?

a) Repousser la limitation sur la taille du buffer pool présente en version 5.1
b) Améliorer les performances en limitant les contentions sur la mutex protégeant le buffer pool
c) Se mettre en conformité avec la norme SQL ANSI 2008

23- Une table a pour clé primaire une colonne id. Que penser d’un index sur les colonnes (name, id) ?

a) L’index peut être simplifié en un index sur la colonne name.
b) L’index peut être simplifié en un index sur la colonne name seulement si la table utilise MyISAM.
c) L’index peut être simplifié en un index sur la colonne name seulement si la table utilise InnoDB.

24- Pour une table InnoDB, quelle est la différence entre les deux motifs d’accès suivants donnés par EXPLAIN :
type: index, key: PRIMARY
type: ALL, key: NULL

a) La clé primaire étant triée, l’accès type: index est plus efficace
b) Les deux type d’accès sont identiques
c) L’accès type:ALL accède directement aux données sans passer par l’index, il est donc plus efficace

25- Que signifie la mention Using filesort dans EXPLAIN ?

a) Le tri demandé dans la requête se fait dans un fichier sur disque
b) Le tri demandé dans la requête se fait dans une table temporaire sur disque
c) Le tri demandé dans la requête n’utilise pas d’index

26- La clé de partitionnement doit faire partie de la clé primaire.

a) Vrai
b) Faux

27- Une configuration master-master actif-actif permet-elle d’augmenter le nombre d’écritures ?

a) Oui : on peut écrire sur les deux serveurs en même temps
b) Non : chaque serveur doit jouer 100% des écritures, la partie reçue en tant que slave est sérialisée

28- Comment garantir qu’un esclave ait au maximum n secondes de retard sur son maître ?

a) Utiliser une réplication master-master, le master actif sera en effet automatiquement ralenti en recevant les binlogs du master passif
b) Utiliser n esclaves
c) Ce n’est pas possible nativement

29- Maatkit contient-il un outil repérant les index redondants ou en doublon ?

a) Oui, mk-index-usage
b) Oui, mk-duplicate-key-checker
c) Oui, mais c’est inutile car la commande CHECK TABLE fait déjà le travail depuis MySQL 5.1

30- Une table MyISAM ayant l’option ROW_FORMAT=FIXED ne peut pas être fragmentée.

a) Vrai
b) Faux

1- b : Toutes les ressources doivent etre étanches entre les instances

2- a : MyISAM garde dans ses méta-données le nombre de lignes de la table

3- b : InnoDB remplit d’abord le 1er fichier, puis le 2nd, on ne peut pas parler de distribution des écritures

4- c : Certains changements de droits n’affectent pas les sessions déjà ouvertes

5- a : Le tablespace principal contient des informations indispensables au bon fonctionnnement d’InnoDB, meme avec innodb_file_per_table

6- c : La réplication ne constitue pas une sauvegarde

7- a : Depuis MySQL 5.1 et la fonctionnalité de plugins, les versions d’InnoDB peuvent sortir indépendamment des versions de MySQL

8- b : En général, MySQL n’utilise qu’un seul index par table et par requete, un index multi-colonnes est donc souvent le plus efficace

9- c

10- a : C’est au cas par cas qu’il faut regarder qui est le plus performant, jointure ou sous-requete

11- c

12- b : Là encore, il faut regarder au cas par cas

13- b : Les autres méthodes sont risquées car elles vont poser des problèmes dans certains cas

14- a : Si vous ne connaissez pas MySQL Sandbox, voici un bon article pour débuter

15- a : En général, ALTER TABLE crée une table temporaire pour chaque modification, mieux vaut donc les regrouper

Faites-moi savoir si certaines réponses vous étonnent, ça pourra être l’occasion de revenir sur ces points dans de prochains posts. Et bien sûr, dans le prochain article vont suivre les 15 questions restantes. Attention, d’une manière générale, les questions qui vont venir sont plus difficiles !!

1- Quand on installe deux instances de MySQL sur la même machine hôte, les deux instances ne peuvent pas partager le même port, mais peuvent partager la même socket.

a) Vrai
b) Faux

2- Quelle est la requête dont l’exécution est immédiate, la table t utilisant le moteur MyISAM et id étant la clé primaire ?

a) SELECT COUNT(*) FROM t
b) SELECT COUNT(*) FROM t WHERE id > 5
c) SELECT id FROM t

3- Quand on n’utilise pas l’option innodb_file_per_table, spécifier plusieurs tablespaces avec l’option innodb_data_file_path permet de distribuer les écritures InnoDB sur plusieurs fichiers.

a) Vrai
b) Faux

4- Les droits d’un utilisateur ont été changés avec la commande GRANT. Que faut-il faire pour être certain que les nouveaux droits soient pris en compte ?

a) Rien
b) Lancer FLUSH PRIVILEGES
c) Tuer les sessions de l’utilisateur si elles existent

5- Quand l’option innodb_file_per_table est activée, sauvegarder les fichiers .ibd n’est pas suffisant.

a) Vrai
b) Faux

6- Quand on met en place une réplication maitre-esclave, il n’est plus nécessaire de faire des sauvegardes, l’esclave possédant une copie des données.

a) Vrai
b) Vrai seulement s’il existe au moins deux esclaves, afin que le système soit redondant
c) Faux

7- Qu’est le plugin InnoDB ?

a) Une version d’InnoDB installable sous forme de plugin pour MySQL 5.1 avec des fonctionnalités supplémentaires par rapport à la version d’InnoDB fournie en standard avec MySQL 5.1
b) Un add-on qui facilite la migration de MySQL vers Oracle
c) Un script permettant d’effectuer des backups à chaud des tables InnoDB

8- Pour répondre à une clause de type WHERE type = « XXX » AND customer_id = 123, quelle est a priori la meilleure indexation ?

a) Aucun index supplémentaire n’est nécessaire, la clé primaire suffit pour ce type de filtrage
b) Un index sur les 2 colonnes type et customer_id
c) Un index sur type et un index sur customer_id

9- Dans une jointure à deux tables, est-il nécessaire d’indexer chaque colonne de la condition de jointure ?

a) Oui
b) Non
c) Seul l’index de la table jointe est utilisé, mais l’optimiseur peut inverser l’ordre de jointure, mieux vaut donc en général indexer les deux colonnes

10- Une sous-requête est parfois plus performant qu’une jointure équivalente.

a) Vrai
b) Faux

11- Quelle est la commande qui permet de savoir quelles partitions sont examinées par une requête ?

a) EXPLAIN
b) EXPLAIN EXTENDED
c) EXPLAIN PARTITIONS

12- Les procédures et fonctions stockées améliorent nettement les performances par rapport à un code similaire côté applicatif.

a) Vrai
b) Ca dépend
c) Faux

13- Pour changer les coordonnées de réplication d’un esclave, quelle est la meilleure méthode ?

a) Editer le fichier master.info
b) Lancer une commande CHANGE MASTER TO
c) Editer le fichier my.cnf

14- Pour mener des tests sur une configuration de réplication circulaire à 3 serveurs, quel outil peut être utilisé pour monter rapidement les serveurs ?

a) MySQL Sandbox
b) Maatkit
c) Aucun outil n’est capable de réaliser cette opération

15- Si on souhaite, sur une même table, modifier le type d’une colonne et en ajouter une autre, quelle est la meilleure stratégie ?

a) Lancer une seule commande ALTER TABLE pour modifier et ajouter en même temps
b) Lancer une commande ALTER TABLE pour modifier, puis une commande ALTER TABLE pour ajouter
c) Lancer une commande ALTER TABLE pour ajouter, puis une commande ALTER TABLE pour modifier

Alors, facile ? Rendez-vous très prochainement pour la deuxième partie du quiz et pour les réponses !

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.