Les vacances étant terminées, nous allons boucler notre tour de vue des index inutiles en voyant quels outils vont nous aider à découvrir les index qui peuvent être supprimés. Le dernier article présentait en effet des indications qui fonctionnent généralement bien mais qui ont l’inconvénient de demander beaucoup de travail manuel et de laisser de côté tout un pan d’index qui peuvent être inutiles : ceux qui ne sont pas en doublon ni redondants, qui n’ont pas une cardinalité faible mais qui ne sont tout simplement pas utilisés par l’application.

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% …

Après avoir constaté dans les articles précédents que les index inutiles causent des baisses de performances non négligeables, nous allons voir dans cet article qu’il n’est pas aussi simple qu’il y paraît de déterminer si un index est utile ou non, même si dans certains cas la réponse semble évidente.

A première vue, trois catégories d’index sont bien placés pour être qualifiés d’inutiles : les index en doublon, les index redondants et les index à faible cardinalité. Regardons chaque catégorie en détail.

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 …

Une manière d’identifier d’où provient des peaks de performance momentanés est de regarder les logs produit par MySQL, soit le slow query log et les binlog. Malheureusement (ou heureusement?), il est possible qu’un grand nombre de requêtes optimisées soit envoyées au serveur, et par conséquent, ne se trouve pas dans le slow query log. Le binlog s’avère donc une source plus fiable.

Comment faire? En utilisant mk-query-digest de la suite d’outil Maatkit. Cet outil permet d’analyse les logs générés par mysqlbinlog et crée un rapport complet de la situation. Il possède une multitude d’options que je vous invite à lire dans la doc officielle, mais voici comment l’utiliser dans sa forme la plus simple:

mysqlbinlog mysql-binlog.003161 | mk-query-digest --type binlog --report-format …

Instrumenter son application correctement représente un pas important dans la recherche des performances optimales. De bons outils permettent également de gagner du temps, qui est toujours précis. Cet article va vous donner un exemple de la valeur ajoutée que peut procurer un bon outil : le simple fait d’obtenir un rapport précis sur un problème rencontré permet de résoudre en 5 minutes un gros problème de performance qui ne trouvait pas de solution depuis des semaines.

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 …

Et voici notre troisième et dernière partie consacrée aux outils d’analyse de requêtes lentes. Aujourd’hui, après le très simple mysqldumpslow et le configurable mysqlsla, nous allons examiner mk-query-digest, un des scripts Perl faisant partie de la suite Maatkit.

mk-query-digest permet d’analyser de nombreux types de journaux et présente un rapport qu’on peut configurer de multiples manières. Contrairement à mysqlsla qui ne sait lire que des fichiers journaux, mk-query-digest offre la possibilité d’analyser d’autres sources de requêtes, par exemple des paquets issus de tcpdump. Un autre point fort de cet outil est le nombre d’options disponibles, qui permettent de filtrer ou classer les entrées analysées de manière à obtenir exactement le rapport que chacun souhaite.

Comme toujours, notre propos va commencer par …

J’adore Maatkit. Je m’en sers régulièrement dans toutes sortes d’occasions. Pour tous les Slaves que je configure, j’ajoute un petit script maison qui utilise mk-table-sync afin valider l’intégrité des données sur le Slave avec le Master. Ce petit script envoie un email avec les différences et les requêtes à exécuter le cas échéant.

J’ai remarqué que mk-table-sync possède certaines limitations, c’est-à-dire que le format de la table et l’encoding joue un rôle important sur la manière dont l’outil effectue ses comparaisons. Les tables sans clé primaire ou d’identifiant unique sont particulièrement problématiques, et c’est tout à fait compréhensible. Par définition, s’il n’y a pas d’identifiant unique, il est impossible d’être 100% sur que l’enregistrement #1 sur le Master correspond à l’enregistrement #1 sur le Slave. En étant …