InnoDB est un moteur extrêmement complexe qui mériterait un livre complet pour expliquer son fonctionnement. Selon les versions, il peut exister plus de 80 paramètres pour contrôler son fonctionnement : pas question de les examiner tous ! Je vais me concentrer sur les 2 principaux, qui devraient suffir dans la majorité des cas.

Le 1er, innodb_buffer_pool_size, contrôle la taille du cache mémoire pour les données et les index. Il s’agit assurément du paramètre de base pour obtenir de bonnes performances InnoDB puisqu’il vous permet de remplacer de nombreuses lectures ou écritures sur disque par des lectures ou écritures en mémoire. Pour le configurer, c’est simple, essayez de mettre la valeur la plus élevée possible… Evidemment, il faut penser à garder un peu de mémoire pour les connexions, les tables temporaires, les éventuelles tables MyISAM… et l’OS !

Le 2nd, innodb_log_file_size, contrôle la taille des redo logs. A quoi servent ces redo logs en quelques mots ? Pour des raisons de performance, quand un client fait une modification dans une table, InnoDB exécute la modification en mémoire instantanément (dans le fameux buffer pool que nous avons appris à configurer ci-dessus) mais garde pour plus tard l’exécution de la modification sur le disque.
Que se passe-t-il si le serveur subit un crash entre le moment où la donnée est écrite en mémoire et le moment où la donnée est écrite sur le disque ? La donnée est perdue tout simplement. Il faut donc un mécanisme supplémentaire pour assurer la persistence des données en cas de crash : ce sont les fameux redo logs. En réalité, au moment où on exécute une modification, InnoDB l’exécute en mémoire et la note également dans ses redo logs avant de signaler au client que la modification est bien enregistrée. En cas de crash, la lecture des redo logs va permettre de reconstituer les données qui étaient en mémoire mais pas encore sauvegardées sur le disque.

Quel est l’intérêt des redo logs par rapport à une écriture directe dans le fichier de données ? En général, les modifications de données successives ont lieu à des endroits radicalement différents, ce qui se traduit pour le disque par de nombreuses écritures aléatoires, extrêmement lentes. Au contraire, écrire des modifications successives dans les redo logs consiste à écrire chaque modification à la fin du fichier : il s’agit là d’écritures séquentielles, nettement plus rapides. Au moment de retranscrire le contenu des redo logs vers les tables, InnoDB pourra en profiter pour regrouper les écritures pour les rendre les plus séquentielles possibles. Ce mécanisme permet donc d’éviter de nombreuses et coûteuses écritures aléatoires.

Et que se passe-t-il quand les redo logs sont pleins ? Il n’est tout simplement plus possible de faire de modifications ! InnoDB tente donc de nettoyer régulièrement ces logs pour qu’il reste toujours de la place.

Bref, si vous m’avez suivi, les redo logs permettent de gagner en performance en écriture, on a donc tout intérêt à configurer une valeur aussi grande que possible. Cependant, il faut également garder à l’esprit qu’en cas de crash, les redo logs vont être utilisés pour restaurer les données, et cette restauration sera d’autant plus longue que la taille des redo logs sera grande… Il va donc falloir trouver un compromis entre ces 2 exigences contradictoires.

Baron de Percona a écrit un très bon article sur le sujet. Sans reprendre dans le détail ce qu’il explique, le principe de son calcul est de déterminer le volume d’écriture en période de pleine charge et de faire en sorte que les redo logs puisse contenir 1 heure d’écriture à pleine charge.

J’en profite au passage pour vous inciter à la méfiance si vous lisez des articles vous parlant de fixer cette variable à 25% de la taille du buffer pool par exemple. C’est faux et d’ailleurs bien souvent irréalisable : à part en MySQL 5.6 et sur les versions récentes de Percona Server, la taille des redo logs est limitée à 4 Go. Avec un buffer pool de 32 Go ou plus, difficile de respecter cette « règle » des 25 %…

Je fais une petite parenthèse sur le paramètre innodb_file_per_table. Ce paramètre fait en sorte que les données de chaque table soient stockées dans un tablespace spécifique au lieu du tablespace principal. Il ne faut pas attendre de cette option des gains en performance, mais plutôt en flexibilité : si vous avez 200 Go de données, au lieu d’avoir un énorme fichier ibdata de 200 Go, vous aurez autant de fichiers que de tables. De plus, si jamais vous supprimez une table, le tablespace spécifique à la table sera supprimé et vous récupérerez l’espace disque correspondant, ce qui ne sera jamais le cas si vous stockez toutes vos données dans le tablespace principal.

A noter que Percona a mis en ligne un outil vous permettant d’obtenir un fichier de configuration basique (c’est-à-dire sans doute pas optimisé au micro-poil près, mais en tout cas sans grossière erreur pouvant coûter très cher).

Et voilà ! En configurant correctement ces 2 paramètres, vous aurez réalisé l’essentiel du paramétrage d’InnoDB ! Evidemment, ensuite, il est possible d’aller un peu plus loin en jouant sur d’autres paramètres comme innodb_flush_log_at_trx_commit ou innodb_flush_method. Mais ce sera peut-être pour un prochain article !

Cache de requêtes

Le cache de requêtes est une excellente idée des années 90 pour accélérer les performances des SELECT. Malheureusement ce cache n’est absolument pas scalable en terme de connexions simultanées, ce qui signifie que dans 99,9% des cas, les performances seront meilleures quand le cache est désactivée.

Par conséquent, le tuning du cache de requêtes est très simple, il vous suffit d’indiquer dans votre fichier de configuration :
query_cache = 0

Pour les plus curieux, sachez que la désactivation du cache de requêtes n’empêche pas le serveur d’utiliser la mutex d’accès au cache de requêtes : même désactivé, le cache de requêtes peut diminuer vos performances !! Dans Percona Server et MySQL 5.5, query_cache = 0 désactive également cette mutex, mais pour les versions antérieures, il vous faudra recompiler le serveur sans support du cache de requêtes pour vous débarasser de cette mutex.

Réplication

La réplication est tellement utile qu’il est difficile de s’en passer : scale-out, haute disponibilité, aide aux backups, slaves dédiés pour les statistiques… la liste des applications est longue !

Sur toutes les instances impliquées dans un schéma de réplication, il faut absolument que chaque instance ait un server-id unique. Si vous utilisez un système de déploiement de configuration, pensez à faire en sorte que le système de déploiement génère lui-même un id qui soit garanti comme étant unique.

Sur le master, il faut également activer le paramètre log_bin pour mettre en route les logs binaires nécessaires à la réplication (et qui sont aussi utiles pour le Point In Time Recovery), par exemple :
log_bin = /data/mysql-bin

Le serveur s’occupe tout seul de numéroter les fichiers et d’en faire la rotation. A ce propos, il peut être pratique de forcer la rotation quand le fichier atteint une taille plus faible que celle par défaut (1 Go) :
max_binlog_size = 100000000
et de purger automatiquement les fichiers au bout d’un certain temps :
expire_logs_days = 7

Est également recommandé l’option sync_binlog = 1 qui assure le flush du log binaire à chaque commit (meilleure assurance contre les pertes de données en cas de crash).

Sur les slaves, il n’est en général pas nécessaire d’activer les logs binaires, sauf si le slave est lui-même un master. Dans ce cas, il faut penser à ajouter le paramètre log_slave_updates, qui indique au serveur d’écrire dans les logs binaires les écritures reçues par la réplication.

La seule autre option vraiment intéressante est read_only = 1, qui empêche tous les utilisateurs n’ayant pas le droit SUPER d’écrire sur le serveur. Cette option peut éviter des gros problèmes de désynchronisations si accidentellement une application tente d’écrire directement sur un slave au lieu d’écrire sur le master.

Ne pas oublier également de configurer un compte pour la réplication avec les droits REPLICATION SLAVE et REPLICATION CLIENT.

Journalisation

Avoir des traces de ce qui se passe dans le serveur est évidemment une très bonne idée, aussi bien pour résoudre les problèmes que pour prendre des mesures préventives. Il existe avec MySQL 3 types de logs : general log pour l’ensemble des connexions et requêtes, slow query log pour les requêtes lentes et error log pour les erreurs et warnings.

Il est préférable d’éviter d’activer le general log en production, hormis pour des périodes courtes pour investiguer sur un problème précis, car les performances s’en ressentent lourdement (et que vous risquez de vous retrouver très vite à court d’espace disque). Cela se traduit par :
general_log = OFF

Le slow query log est particulièrement utile pour repérer les requêtes les plus coûteuses de votre application. Toutes les requêtes au-delà d’un seuil que vous définissez sont écrites et peuvent servir à générer un rapport des requêtes les plus lentes. Une configuration typique est la suivante :
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

Enfin le log d’erreur devrait être activé, soit par le paramètre log_error soit en écrivant dans syslog, avec le paramètre syslog que vous trouverez généralement dans la section [mysqld_safe]. Sachez que les 2 solutions ont des avantages et des inconvénients, l’inconvénient étant toujours que vous risquez de perdre la trace d’erreurs à cause de la rotation de votre fichier de log. Vous trouverez plus d’informations dans ce billet.

Nous verrons dans le dernier article de cet série les paramètres les plus importants pour InnoDB. D’ici là, bonnes fêtes de fin d’année !

bind-address
Cette variable permet les connexions TCP à l’adresse IP indiquée. C’est la 1ère variable à regarder si vous constatez un problème d’accès et que les droits de l’utilisateur sont corrects.
En général, on utilise cette variable de 2 manières :
- bind-address = 127.0.0.1 pour n’autoriser que les connexions TCP en local
- en commentant la variable pour n’avoir aucune restriction

A noter qu’il n’est (malheureusement) pas possible d’indiquer une liste d’adresses IP pour restreindre les connexions TCP à plusieurs hôtes, dans ce cas, il faut passer par des règles de firewalls.

skip-name-resolve
Lorsqu’un client se connecte au serveur, celui-ci fait 2 requêtes DNS. Le DNS pouvant être lent, c’est souvent une bonne idée d’utiliser cette variable pour désactiver complètement les requêtes DNS. Seule conséquence contraignante : le champ host des utilisateurs ne peut plus être un nom de domaine, mais uniquement une adresse IP (vous pouvez continuer à utiliser les wildcards, par exemple 192.168.%).

max_connections
C’est la variable qui contrôle le nombre de connexions simultanées au serveur. Si vous voyez régulièrement des erreurs ‘Too many connections‘ lorsque des clients essaient de se connecter, il s’agit de la variable à regarder, la valeur par défaut (100 ou 150 selon les versions) pouvant être trop faible selon le type d’applications.

A noter qu’il n’est pas conseillé de mettre systématiquement cette variable à un nombre très élevé, puisque plus le nombre de connexions simultanées est élevé, plus le serveur risque d’être sujet à des problèmes de contentions internes et risque d’être peu performant. Parfois un trop grand nombre de connexions simultanées cache un problème de conception dans l’application.

A noter également que même quand le nombre de connexions ouvertes a atteint max_connections, il est toujours possible de se connecter au serveur avec un utilisateur qui dispose du droit SUPER. Le but est de pouvoir faire des SHOW PROCESSLIST pour comprendre ce qu’il se passe (et éventuellement quelques KILL bien sentis…).

datadir
Il s’agit de l’emplacement du répertoire de données. Vous n’avez pas besoin de le changer si votre volumétrie de données reste dans la gamme des centaines de Mo ou moins, mais dès que vous prévoyez d’atteindre des tailles conséquentes, il est plus que conseillé d’indiquer un répertoire se trouvant dans une partition où l’espace disque est suffisant.

old_passwords
Avant la version 4.1, MySQL utilisait une méthode de cryptage des mots de passe très faible, toujours disponible sur les versions actuelles quand on active ce fameux paramètre (old_passwords = 1).

En général, on trouve ce fameux paramètre sur de vielles applications « parce qu’on ne va pas s’amuser à changer tous les mauvais de passe même si on sait que ce serait mieux ».

En réalité, même quand on désactive ce paramètre, un client est toujours capable de se connecter lorsque son mot de passe est crypté avec l’ancienne méthode. Il n’y a donc que des avantages à désactiver old_passwords, sauf si bien sûr vous utilisez encore des librairies ne connaissant que l’ancien cryptage (ce qui devrait être hautement improbable, le changement dans MySQL datant de 2004 !).

Quelques autres variables intéressantes
Selon les cas, il peut aussi être pertinent de regarder du côté des variables suivantes : thread_cache_size, tmp_table_size, max_heap_table_size, table_definition_cache, table_open_cache.

Je signale également un cas particulier : sort_buffer_size. Vous avez tout intérêt à la laisser à sa valeur par défaut et donc à la commenter si vous la trouvez dans un fichier de configuration. Pour la petite histoire, j’ai mis fin aux crashes aléatoires d’un serveur en commentant simplement cette petite variable. Le scénario était le suivant avant cette modification : sort_buffer_size = 512M + plusieurs requêtes simultanées avec des gros tris => la RAM vient à manquer => OOM killer se met en route et tue mysqld…

Dans le prochain épisode, nous verrons les variables les plus importantes concernant le cache de requêtes, la réplication et les journaux.

Le programme de la rencontre est déjà disponible, n’oubliez pas de vous inscrire si vous comptez venir, le nombre de places étant limité.

Voici le code magique qui vous donnera droit à une réduction de 40£ : come-c-talk, que vous pourrez saisir en vous enregistrant.

Pour plus d’informations sur Percona Live, vous pouvez aller voir le site, et surtout le programme.
Enfin, vous pouvez vous inscrire au groupe LinkedIn créé pour l’occasion par notre ami Cédric.

See you there!

PS : promis, dans le prochain post, vous trouverez plus de technique et moins de liens !!

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.