dbnewz » index

Méthodes de suppression des index inutiles

stephane — Mon, 05 Sep 2011 15:59:32 +0000

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% 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 candidats à la suppression

stephane — Wed, 06 Jul 2011 13:10:14 +0000

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 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.

Le coût des index inutiles – 2nde partie

stephane — Fri, 27 May 2011 15:50:34 +0000

Dans l’article précédent, nous nous étions demandés quelle était la dégradation des performances en écriture quand on ajoute des index. On peut élargir la réflexion en se penchant sur les conditions qui améliorent ou diminuent la vitesse d’écriture dans une table.

Avant de commencer de nouvelles expérimentations, rappelons les conditions du test. La table utilisée a la structure suivante :
CREATE TABLE ( id int(11) NOT NULL AUTO_INCREMENT, col_a varchar(30) NOT NULL DEFAULT '', col_b varchar(30) NOT NULL DEFAULT '', col_c varchar(30) NOT NULL DEFAULT '', PRIMARY KEY (id) );
et nous cherchons à insérer un millions de lignes à l’aide de la commande LOAD DATA INFILE.

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.

Le coût des index inutiles

stephane — Mon, 16 May 2011 14:48:02 +0000

On vous a tout le temps dit et redit que les index étaient indispensables pour les performances en lecture d’une base de données et vous avez eu droit à des exemples spectaculaires où les temps de réponses sont divisés par 10 000 ou par 1 000 000 rien qu’en ajoutant un index judicieux. Bien. On vous a également prévenu que chaque index posé dégrade les écritures et qu’il ne faut donc pas en abuser. Mais vous a-t-on déjà montré quel type de dégradation en écriture on peut attendre quand on ajoute un index ? C’est ce dont nous allons parler dans cet article.

Prenons une table InnoDB toute simple :

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

et testons l’influence des index sur le temps de chargement d’un million de lignes au moyen d’un LOAD DATA INFILE.

Cas 1, données et index tiennent en mémoire (innodb_buffer_pool suffisamment grand) :
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

Cas 2, données et index ne tiennent plus en mémoire :
Seulement la clé primaire : 22,5s
Clé primaire + index sur col_a : 370s
Clé primaire + index sur col_a + index sur col_b : 1144s
Clé primaire + index sur (col_a,col_b) : 716s

Quelles conclusions pouvons-nous faire de ces tests ? Tout d’abord, les insertions sont nettement plus rapides quand la table tient en mémoire. Ce n’est pas une surprise, tout va toujours plus vite lorsqu’on travaille en mémoire que lorsqu’on travaille sur le disque. Les différences sont cependant spectaculaires, puisque le temps de chargement dans le cas 2 est x1,5 dans le meilleur cas et x25 dans le pire des cas.

On remarque également qu’à chaque index ajouté, le temps de chargement augmente de manière très importante (x3 avec 2 index pour le cas 1 et x50 pour le cas 2), même lorsque la table tient en mémoire.

La conclusion de ce petit test est donc la suivante : les index inutiles dégradent très fortement les performances en écriture, et cela même si les données tiennent intégralement en mémoire. Si vous avez des problèmes de capacité d’écriture sur vos serveurs MySQL, par exemple avec des slaves qui ont du mal à répliquer les requêtes du master sans prendre de retard, une bonne piste consiste à partir à la chasse aux index inutiles. Reste une dernière question : comment déterminer les index inutiles ? C’est loin d’être évident, et nous en reparlerons en détail dans un prochain article.

Instrumentation et performance

stephane — Mon, 24 Jan 2011 16:52:21 +0000

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 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 ?

le trigger au secours des function-based index (FBI)

arnaud — Wed, 01 Apr 2009 06:36:55 +0000

Constat : les FBI (function-based index) ne sont pas disponibles en MySQL.

Comment faire dans ce cas pour obtenir par exemple l’équivalent de l’index suivant ?

CREATE INDEX idx_str_len ON my_table (length(str));

Une des solutions les plus simples consiste à utiliser un trigger qui assurera la mise à jour d’une colonne supplémentaire que l’on créera dans la table cible.

Partons de la table suivante :

CREATE TABLE `t` ( `id` mediumint(8) unsigned NOT NULL auto_increment, `date` timestamp NOT NULL, `str` varchar(100) NOT NULL default '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM;

Le but est de pouvoir obtenir une réponse rapide à la requête suivante :

select sql_no_cache count(*) from t where length(str) between 20 and 70;

Afin de simuler un jeu d’essai similaire à ma table de production, j’alimente ma table de test grâce à une procédure stockée déjà évoquée sur dbnewz.

Je la modifie ici afin d’obtenir une longueur aléatoire pour ma chaîne de caractère « str » :

delimiter // CREATE PROCEDURE fill_table(nb_rows INT) BEGIN DECLARE i INT DEFAULT 0; REPEAT SET i = i + 1; INSERT INTO t (str) VALUES(repeat('a', round(rand()*100))); UNTIL i >= nb_rows END REPEAT; END; // delimiter ;

Afin de valider deux scénarios pour ce billet, j’ai utilisé deux machines, une machine perso et un serveur pro. Deux configurations différentes : la perso n’est absolument pas « tunée », en configuration strictement d’origine (5.1.32), la seconde a des processeurs et de la RAM à revendre.
J’afficherai donc les temps d’exécution des deux machines à titre de comparaison.

Pour renseigner ma table de test à hauteur de 2 millions d’enregistrements, j’appelle ma procédure stockée :

Perso :
mysql> call fill_table(2000000);
Query OK, 1 row affected (1 min 52.97 sec)

Pro :
mysql> call fill_table(2000000);
Query OK, 1 row affected (42.23 sec)

Je souhaite tester ma requête sous InnoDB, je modifie le moteur de la table :

mysql> alter table t engine=’innodb’;
Query OK, 2000000 rows affected (43.57 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

mysql> alter table t engine=’innodb’;
Query OK, 2000000 rows affected (13.10 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

J’ai testé pour vous : il est bien plus rapide d’insérer en MyISAM et de faire l’ALTER en InnoDB que d’insérer directement en InnoDB :

Test de chargement avec table en InnoDB d’origine sur la machine perso :
mysql> call fill_table(100000);
Query OK, 1 row affected (1 min 14.15 sec)

=> Déjà 30 secondes de plus (70% plus lent) pour 20x moins de données !

La machine pro (en 5.0.56) est bien plus rapide mais valide elle aussi la stratégie de passer par MyISAM en premier lieu :
Chargement d’une table en InnoDB sur serveur pro :
mysql> call fill_table(2000000);
Query OK, 1 row affected (1 min 11.16 sec)

=> A comparer avec les 42 sec (chargement MyISAM natif) + 13 sec (alter InnoDB) = 55 s. Au moins 30% plus rapide.

On obtient une table contenant des enregistrements du type :

mysql> select * from t limit 5;
+—-+———————+——————-
| id | date | str
+—-+———————+——————-
| 1 | 2009-03-30 22:18:02 | aaaaaaaa
| 2 | 2009-03-30 22:18:02 | aaaaaaaaaaaaaaaa
| 3 | 2009-03-30 22:18:02 | aaaaaaaaaaaaaaaaaaaaaaa
| 4 | 2009-03-30 22:18:02 | aaaaaaaaaaa
| 5 | 2009-03-30 22:18:02 | aaa
+—-+———————+——————–

Nous voici donc avec un jeu d’essai raisonnable, prêt à en découdre avec cette requête…

mysql> explain select sql_no_cache count(*) from t where length(str) between 20 and 70;

*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2015427
Extra: Using where
1 row in set (0.00 sec)

… Au temps d’exécution pitoyable. Sur la machine perso, j’obtiens en moyenne :

mysql> select sql_no_cache count(*) from t where length(str) between 20 and 70;
+———-+
| count(*) |
+———-+
| 1019970 |
+———-+
1 row in set (1.83 sec)

Sur le serveur pro :

mysql> select sql_no_cache count(*) from t where length(str) between 20 and 70;
+———-+
| count(*) |
+———-+
| 1020008 |
+———-+
1 row in set (0.82 sec)

L’innodb_buffer_pool_size de la machine perso est complètement sous-dimensionné pour contenir toutes les données de ma table. L’intérêt ici est de tester ce qui se passe quand les données ne sont pas montées en RAM (comportement de MyISAM qui charge les datas dans le cache OS).

Constatons les « dégats » sur la machine perso :

… le jour et la nuit avec :

Voyons si un index peut changer la donne ? Plaçons-le sur la colonne « str » :

mysql> create index idx_str on t (str);
Query OK, 2000000 rows affected (1 min 1.95 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

mysql> create index idx_str on t (str);
Query OK, 2000000 rows affected (24.95 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

Le nouveau plan d’exécution est le suivant :

mysql> explain select sql_no_cache count(*) from t where length(str) between 20 and 70;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: index
possible_keys: NULL
key: idx_str
key_len: 102
ref: NULL
rows: 1957767
Extra: Using where; Using index
1 row in set (0.00 sec)

Nous sommes dans le cas d’un covering index mais celui-ci n’est pas hélas pas d’une grande utilité sur la machine perso :

mysql> select sql_no_cache count(*) from t where length(str) between 20 and 70;
+———-+
| count(*) |
+———-+
| 1019970 |
+———-+
1 row in set (1.98 sec)

On frôle les 2 secondes.

Sur la machine de prod c’est en revanche légèrement plus rapide :

mysql> select sql_no_cache count(*) from t where length(str) between 20 and 70;
+———-+
| count(*) |
+———-+
| 1020008 |
+———-+
1 row in set (0.73 sec)

Stratégie : rajouter une colonne « str_nb » à ma table t et mettre à jour cette colonne selon la longueur de « str ».

Machine Perso :
mysql> ALTER table t ADD str_nb tinyint unsigned, ADD index idx_str_nb(str_nb);
Query OK, 2000000 rows affected (1 min 9.22 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

mysql> UPDATE t SET str_nb = length(str);
Query OK, 2000000 rows affected (2 min 3.97 sec)
Rows matched: 2000000 Changed: 2000000 Warnings: 0

Serveur Pro :
mysql> ALTER table t ADD str_nb tinyint unsigned, ADD index idx_str_nb(str_nb);
Query OK, 2000000 rows affected (30.91 sec)
Records: 2000000 Duplicates: 0 Warnings: 0

mysql> UPDATE t SET str_nb = length(str);

Query OK, 2000000 rows affected (1 min 22.54 sec)
Rows matched: 2000000 Changed: 2000000 Warnings: 0

mysql> explain select sql_no_cache count(*) from t where str_nb between 20 and 70\G

*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: range
possible_keys: idx_str_nb
key: idx_str_nb
key_len: 2
ref: NULL
rows: 914077
Extra: Using where; Using index
1 row in set (0.00 sec)

Notre requête modifiée tire parti du nouvel index :

mysql> select sql_no_cache count(*) from t where str_nb between 20 and 70;
+———-+
| count(*) |
+———-+
| 1019970 |
+———-+
1 row in set (0.99 sec)

Sur la machine de prod :

mysql> select sql_no_cache count(*) from t where str_nb between 20 and 70;
+———-+
| count(*) |
+———-+
| 1020008 |
+———-+
1 row in set (0.37 sec)

Résultat de ces tests : tirer parti d’une colonne « précalculée » permet de diviser par deux le temps d’exécution sur les deux machines.

Comment maintenir à jour cette colonne ?

C’est là que les triggers rentrent en jeu, on en crée deux :

Le premier concerne les INSERT…

DELIMITER | CREATE TRIGGER maj_str_nb_ins BEFORE INSERT ON t FOR EACH ROW BEGIN SET NEW.str_nb = length(NEW.str); END; | DELIMITER ;

… Et le second les UPDATE :

DELIMITER | CREATE TRIGGER maj_str_nb_upd BEFORE UPDATE ON t FOR EACH ROW BEGIN SET NEW.str_nb = length(NEW.str); END; | DELIMITER ;

Le mot clé « NEW » permet de faire référence à la nouvelle donnée qui est insérée. Dans le cadre d’un UPDATE il existe également le mot clé « OLD » qui permet de manipuler l’ancienne donnée, celle qui va être mise à jour.

Une fois insérés, ces triggers s’occuperont pour nous de mettre à jour automatiquement la colonne « str_nb ». Quelques exemples :

mysql> insert into t (str) values (‘dbnewz’);
Query OK, 1 row affected (0.45 sec)

mysql> select * from t where id = 2000001;
+———+———————+——–+——–+
| id | date | str | str_nb |
+———+———————+——–+——–+
| 2000001 | 2009-04-01 00:35:58 | dbnewz | 6 |
+———+———————+——–+——–+

mysql> update t set date = ‘2009-04-01 03:33:33′ where id = 2000001;
Query OK, 1 row affected (0.35 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from t where id = 2000001;
+———+———————+——–+——–+
| id | date | str | str_nb |
+———+———————+——–+——–+
| 2000001 | 2009-04-01 03:33:33 | dbnewz | 6 |
+———+———————+——–+——–+
1 row in set (0.00 sec)

mysql> update t set str = ‘MySQL’ where id = 2000001;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from t where id = 2000001;
+———+———————+——-+——–+
| id | date | str | str_nb |
+———+———————+——-+——–+
| 2000001 | 2009-04-01 00:38:18 | MySQL | 5 |
+———+———————+——-+——–+
1 row in set (0.00 sec)

A vous de tester si ces triggers peuvent correspondre à un cas que vous cherchez à résoudre, dans ce cas précis, ils fonctionnent.

Merci à Jonathon Coombes avec qui j’ai échangé autour de ce sujet.

Les covering index, de la théorie à la pratique avec MyISAM et InnoDB

arnaud — Wed, 19 Nov 2008 23:56:59 +0000

Pour faire suite au dernier schéma sur les structures comparées d’un index MyISAM et InnoDB, ce billet a pour but de détailler une optimisation nommée covering index.
On appelle ainsi un index lorsqu’il « couvre » l’intégralité des données recherchées et évite ainsi un parcours des enregistrements souvent basé sur des random I/O, spécialement couteux sur disque.

A propos des random I/O, voici un court extrait d’un billet précédent sur les SSD :

Sur un disque classique un “random read” entraîne (du plus couteux au moins couteux) :
- le déplacement de la tête de lecture/écriture sur la bonne piste (”seek time”)
- une fois la tête sur la bonne piste, il faut encore repérer sur celle-ci le bloc secteur demandé (”rotational latency”)
- la lecture et la transmission de la donnée vers le système.

Les quelques chiffres suivants permettent de mesurer les conséquences du paragraphe précédent et ainsi de mieux visualiser les enjeux soulevés par les covering index.

On se base ici sur la base d’un enregistrement de 100 bytes. Notez que ces valeurs sont des ordres de grandeur :

En mémoire :
Sequential read : 5 000 000 read/s (500 Mb /s)
Random read : 250 000 read/s (25 Mb /s)

=> En mémoire, un coefficient x20 existe entre les performances en sequentiel et en lecture aléatoire.

Sur disque :
Sequential read : 500 000 r/s (50 Mb /s)
Random read : 100 r/s (10 Kb /s)

=> Sur disque, un coefficient x5000 (!) existe entre les performances en sequentiel et en lecture aléatoire.

(Source : MySQL High Performance 2nd Edition)

On note qu’entre un parcours séquentiel sur disque (full scan table) et le même parcours en mémoire, il existe un facteur 10… A comparer avec un facteur 2500 pour du random I/O entre un parcours mémoire et son homologue sur disque.
Pas de chance, c’est le parcours basé sur des random I/O qui en général permet de retrouver un enregistrement à partir d’un index (la clé primaire « clustered » d’InnoDB mise à part : raccrochez-vous au schéma pour comprendre pourquoi).

Nous avons donc tout intérêt à tenter de minimiser ce type de parcours grâce aux covering index.

Les covering index : de la théorie…

Un covering index doit rassembler deux qualités :
- Etre l’index choisi par MySQL pour résoudre votre requête
- Contenir l’intégralité des champs recherchés (ceux du SELECT)

Si vous avez sous les yeux le fameux schéma, vous voyez que dans le cas de MyISAM par exemple, il existe en effet un « saut » à effectuer entre la valeur indexée (peu importe que l’index soit primaire ou secondaire) et l’enregistrement. Dans le cas d’un covering index il n’y a plus besoin d’effectuer ce saut puisque la donnée recherchée se trouve déjà intégralement dans l’index.

Nous allons le voir maintenant, c’est au développeur affuté de rechercher ce type d’optimisations. Pour cela une bonne connaissance des caractéristiques de chaque moteur de stockage utilisé est nécessaire.

Si vous maîtrisez le principe du leftmost prefixing et si en plus vous tirez parti d’une table InnoDB à la clé primaire ajoutée derrière chaque index secondaire, voilà qui devrait vous éviter de créer des index inutiles en profitant au maximum des forces en présence !

… à la pratique

Conçu autour de la base world, voici un exemple concret des différences entre MyISAM et InnoDB dont vous devez tenir compte pour vos stratégies d’indexation.

Nous partons d’une table MyISAM qui possède deux index, sa clé primaire (ID) et un index que j’ai crée sur le « countrycode » :

mysql> SHOW INDEX FROM city\G
***** 1. row ****
Key_name: PRIMARY
Seq_in_index: 1
Column_name: ID
Cardinality: 4321
[...]
**** 2. row ****
Key_name: idx_countrycode
Seq_in_index: 1
Column_name: CountryCode
Cardinality: 720
[...]

Testons un premier EXPLAIN :

mysql> EXPLAIN SELECT countrycode, id FROM city WHERE countrycode=’fra’ ORDER BY id ASC\G
***** 1. row ****
id: 1
select_type: SIMPLE
table: city
type: ref
possible_keys: idx_countrycode
key: idx_countrycode
key_len: 3
ref: const
rows: 39
Extra: Using where; Using filesort
1 row in set (0.00 sec)

Cette table sera parcourue selon son index « idx_countrycode », cependant vu que la colonne « id » est également nécessaire pour les résultats, il y’a un saut systématique à chaque entrée de l’index vers les enregistrements correspondants (c’est le « saut » entre le fichier .MYI et le .MYD représenté sur le schéma).

A noter que nous avons ici un filesort c’est à dire un tri supplémentaire effectué par le serveur MySQL pour classer nos résultats. Certes, l’index contient des données ordonnées mais il s’agit ici des valeurs de « countrycode », pas de celles concernant la colonne « id ».

Tentons maintenant une modification du moteur de stockage de la table suivie du même EXPLAIN :

mysql> ALTER TABLE city ENGINE=InnoDB;
Query OK, 4079 rows affected (0.45 sec)
Records: 4079 Duplicates: 0 Warnings: 0

mysql> EXPLAIN SELECT countrycode, id FROM city WHERE countrycode=’fra’ ORDER BY id ASC\G
***** 1. row ****
id: 1
select_type: SIMPLE
table: city
type: ref
possible_keys: idx_countrycode
key: idx_countrycode
key_len: 3
ref: const
rows: 40
Extra: Using where; Using index
1 row in set (0.02 sec)

Explain nous gratifie d’un « USING INDEX », cela signifie que nous sommes dans le cas d’un « covering index ». Ne pas confondre en effet le libellé « index » dans la colonne « type » de EXPLAIN, qui signifie que tout l’index est parcouru, avec le « Using index » de la colonne extra qui indique un covering index.

Pour en revenir au schéma, puisque c’est le support de ce billet, nous sommes passés du côté gauche du dessin (MyISAM), au côté droit (InnoDB). Remarquez comment est formé l’index secondaire sous InnoDB… Il contient la valeur de la clé primaire, c’est une caractéristique très importante puisque c’est comme si notre index placé simplement sur « countrycode » était en fait un index composé des champs (countrycode, id).

Nous sommes donc bien dans le cas d’un covering index puisque cette fois l’intégralité des données recherchées (le countrycode et « id ») sont contenues dans l’index, aucun « saut » supplémentaire vers les enregistrements n’est nécessaire, autant de random I/O de gagnés.

Nous aurions pu obtenir la même chose avec MyISAM mais en spécifiant cette fois un index composé, pour cela on repasse le moteur de stockage en MyISAM puis on crée l’index :

mysql> ALTER TABLE city ENGINE=myisam;
Query OK, 4079 rows affected (0.23 sec)
Records: 4079 Duplicates: 0 Warnings: 0

mysql> CREATE INDEX idx_countrycode_id ON city(countrycode,id);
Query OK, 4079 rows affected (0.25 sec)
Records: 4079 Duplicates: 0 Warnings: 0

mysql> EXPLAIN SELECT id,countrycode FROM city WHERE countrycode=’fra’ ORDER BY id ASC\G
***** 1. row ****
table: city
type: ref
possible_keys: idx_countrycode,idx_countrycode_id
key: idx_countrycode_id
key_len: 3
ref: const
rows: 40
Extra: Using where; Using index
1 row in set (0.00 sec)

Inutile en revanche de créer ce même index composé sous InnoDB puisqu’il existe en fait déjà… Nous ne rajouterions dans ce cas qu’une possibilité supplémentaire à étudier inutilement pour l’optimiseur MySQL sans parler du temps de perdu à mettre à jour un index redondant.

« Combien d’index inutiles ai-je donc dans ma base à l’heure actuelle ? » est peut-être la question que vous vous posez désormais ?

Le tips dbnewz : allez jeter un oeil du côté du « maatkit« , cet ensemble de scripts perl contient justement un outil, le « mk duplicate key checker » qui a justement pour but de vous aider à détecter les doublons.

Notez que dans certains cas particuliers, un index peut volontairement avoir été crée bien que redondant avec un autre index existant. En effet il est parfois préférable de ne pas « alourdir » un index déjà composé de plusieurs champs, exemple un covering index, ou bien encore un index numérique spécialement impliqué dans des jointures qui verrait d’un mauvais oeil ce VARCHAR que vous souhaitez lui ajouter… Cela pourrait engendrer un ralentissement sur les requêtes précedemment basées sur les index que vous souhaitez « enrichir ».

Le « mk duplicate key checker » vous apporte les candidats sur un plateau, à vous d’apporter la valeur ajoutée finale

A retenir :

- Les covering index constituent une optimisation très intéressante pour éviter de couteux random I/O, notamment sur disque. Ayez à l’esprit qu’ils existent et profitez des caractéristiques propres à InnoDB dans ce domaine (présence de la clé primaire derrière chaque index secondaire) pour optimiser vos requêtes sans créer d’index redondants.

- Dans certains cas un covering index peut également vous aider à faire disparaître un disgracieux « Using filesort » dans la colonne « Extra » (la preuve dans notre exemple).

Dessine-moi MySQL : structure d’un index MyISAM et InnoDB

arnaud — Thu, 23 Oct 2008 22:41:43 +0000

Deuxième exemplaire (traduire « 2ème essai ») concernant ces schémas « à main levée », au menu du jour une comparaison entre la structure d’un index MyISAM et celle d’un index InnoDB :

J’ai tenté de tenir compte de vos commentaires précédents, notamment sur les majuscules, est-ce plus lisible ?

Selon les « règles » établies pour cette série « Dessine-moi MySQL », les schémas doivent être suffisamment explicites pour ne pas nécessiter d’explications supplémentaires…
Cependant, vu que je n’ai pas 10 ans d’école d’arts graphiques derrière moi (ça s’est vu ?), et que chaque règle a son exception, je rajouterai tout de même ceci :

Sous MyISAM, il n’y a pas de différence entre une clé primaire et un index « classique » du point de vue de leur structure, ils sont implémentés de la même façon : ils sont triés et pointent vers le ou les enregistrements correspondants. A noter que MyISAM stocke les enregistrements dans l’ordre où ils sont insérés.

En revanche sous InnoDB, une clé primaire est un index dit « clustered« . L’index est dans ce cas « accolé » aux données, il n’y a pas de « saut » supplémentaire à effectuer pour aller chercher l’enregistrement une fois qu’on est positionné sur la valeur recherchée de la clé primaire.
Avec InnoDB, les enregistrements sont stockés non pas dans l’ordre d’insertion mais triés selon la clé primaire.

Rajoutons pour terminer que sous InnoDB, un index secondaire contient systématiquement la clé primaire. C’est en effet la clé primaire qui permet de retrouver l’enregistrement recherché.
Deux conséquences :
- il faut bien choisir sa clé primaire (concise de préférence puisque celle-ci sera présente dans chaque index secondaire).
- le fait que la clé primaire soit présente sur chaque index secondaire permet « d’émuler » la présence d’un index supplémenaire sur votre table, autrement dit il existe des stratégies d’optimisation au rayon des covering index à ce sujet…

Ce dernier point sonne comme un proverbe chinois ? Alors ne manquez pas le prochain épisode sur les covering index, le support de cours est justement sous vos yeux

Cardinalité, sélectivité et distributivité d’un index MySQL : quel impact sur le plan d’exécution ?

arnaud — Thu, 04 Sep 2008 22:37:26 +0000

Nouveau volet de notre série consacrée aux index, la notion de sélectivité d’un index est ici à l’honneur.
Souvenez-vous du billet précédent : notre table de test contient 1 million de lignes et un champ « flag » à la cardinalité très faible : 2.

Cardinalité ? Sélectivité ? Avant d’aller plus loin, deux définitions s’imposent. Tout d’abord la cardinalité d’un index : c’est le nombre de valeurs uniques qu’il contient.

La sélectivité d’un index se calcule elle de la façon suivante :

Selectivité = Cardinalité(Idx) / Nombre total d’enregistrements dans la table
Résultat des courses notre index à une sélectivité de 2 /1 000 000 = 2e-6, qui a dit « peu sélectif » ?

A l’opposé d’une si faible sélectivité on trouve celle d’une clé primaire puisque celle-ci a une selectivité de 1. Exprimé autrement : à une « entrée » de la clé primaire ne correspond qu’un seul enregistrement dans la table.

D’où la règle générale suivante : plus un index est sélectif, plus il est efficace, c’est à dire capable d’identifier rapidement la ou les données recherchées.

L’optimiseur MySQL est chargé de transformer votre requête en un plan d’exécution le plus efficace possible, suit-il à la lettre cette règle générale ?

Vous vous doutez bien que non…

Rentrée oblige : le cas d’école

Débutons par le cas « standard », celui qui effectivement illustre qu’un index sélectif est efficace. Un tel index a donc toutes les chances d’être choisi par l’optimiseur MySQL lors de la conception du plan d’exécution de la requête (s’il est pertinent pour celle-ci bien sûr).

On utilise ici la base de test sakila afin d’afficher la liste des films de l’acteur dont le nom est ‘CRUZ’ :
mysql> EXPLAIN SELECT f.title FROM film f, actor a, film_actor fa WHERE a.actor_id = fa.actor_id AND fa.film_id = f.film_id AND a.last_name = 'CRUZ'\G

*************************** 1. row id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,idx_actor_last_name key: idx_actor_last_name key_len: 137 ref: const rows: 1 Extra: Using where; Using index *************************** 2. row id: 1 select_type: SIMPLE table: fa type: ref possible_keys: PRIMARY,idx_fk_film_id key: PRIMARY key_len: 2 ref: sakila.a.actor_id rows: 13 Extra: Using index *************************** 3. row id: 1 select_type: SIMPLE table: f type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 2 ref: sakila.fa.film_id rows: 1 Extra: 3 rows in set (0.00 sec)

La commande EXPLAIN indique le plan d’exécution de la requête : quelles informations en tirer du point de vue des index utilisés ?

L’optimiseur a tout d’abord décidé de restreindre notre recherche grâce au critère « nom de l’acteur », pour cela il utilise l’index « idx_actor_last_name » de la table « actor ».
« Using index » indique que nous sommes ici dans le cas d’un « covering index« , c’est à dire qu’il est inutile pour MySQL d’aller lire les enregistrements puisque toute l’information recherchée (le nom de l’acteur) est présente dans l’index. Dans le cas d’une table MyISAM cela signifie que seul le fichier .MYI (index) est lu, inutile d’aller lire le .MYD (data).

Jetons un oeil aux index présents sur cette table afin d’en savoir un peu plus sur l’index utilisé (idx_actor_last_name) :
mysql> SHOW INDEX FROM ACTOR\G *************************** 1. row Table: ACTOR Non_unique: 0 Key_name: PRIMARY Seq_in_index: 1 Column_name: actor_id Collation: A Cardinality: 200 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: *************************** 2. row Table: ACTOR Non_unique: 1 Key_name: idx_actor_last_name Seq_in_index: 1 Column_name: last_name Collation: A Cardinality: 200 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: 2 rows in set (0.02 sec)

A priori notre index a une cardinalité de 200… C’est à dire que d’après MySQL, celui-ci contient approximativement (dixit la doc) 200 valeurs uniques. Une estimation à prendre en effet avec des pincettes puisque le champ indexé n’en contient lui-même que 121 :
mysql> SELECT COUNT(DISTINCT(last_name)) FROM actor; +----------------------------+ | COUNT(DISTINCT(last_name)) | +----------------------------+ | 121 | +----------------------------+ 1 row in set (0.06 sec)

Calculons plutôt la sélectivité de l’index à partir des chiffres suivants :
S = 121 / 200 (nb d’enregistrements dans la table)
S = 0,605

C’est moins bon qu’une sélectivité de 1 bien sûr, mais cela dit cet index permet de mettre la main relativement rapidement sur le nom recherché. La distributivité des données est en effet plutôt « homogène ». Entendre par là qu’un seul acteur ne représente pas 95% de la table, ce qui fausserait l’idée que l’on se fait sur la sélectivité de l’index… En effet celle-ci ne prend pas en compte (en tout cas dans la formule) la distributivité des données.

Concernant les approximations relevées ci-dessus sur les cardinalités de nos index, cet article est entièrement tourné vers ce phénomène. A lire !

Voici un aperçu de la distributivité de la colonne « last_name » :

mysql> SELECT last_name, COUNT(last_name) as nb FROM actor GROUP BY last_name ORDER BY nb DESC LIMIT 5; +-----------+----+ | last_name | nb | +-----------+----+ | KILMER | 5 | | NOLTE | 4 | | TEMPLE | 4 | | PECK | 3 | | ALLEN | 3 | +-----------+----+ 5 rows in set (0.00 sec)

Le nom d’acteur le plus représenté parmi les 121 noms de la table « actor » apparaît « seulement » 5 fois, on peut donc dire qu’au pire l’index posé sur « last_name » correspond à 5 enregistrements de la table. Par ailleurs, la moitié environ des noms d’acteur présents dans la table sont uniques.

Pour revenir à notre plan d’exécution, MySQL a donc utilisé pour cette première étape de « sélection » un index plutôt sélectif.

Etape suivante : la jointure entre la table « actor » et « film_actor ».

L’attribut « ref » affiché par la commande EXPLAIN indique que la table « film_actor » sera parcourue pour chaque valeur correspondante de l’index « idx_actor_last_name ». Cet index n’étant pas unique, il existe en effet des cas où à une valeur de l’index, mettons « KILMER », vont correspondre 5 enregistrements dans la table « film_actor ». Ce parcours n’est ici pas pénalisant puisque nous avons encore une fois affaire à un « covering index », les enregistrements de la table ne sont pas accédés puisque tout ce que nous recherchons est déjà dans l’index, une telle optimisation est la bienvenue !

Nous reparlerons des covering index dans un billet ultérieur, mais vous connaissez maintenant le principe.

Dernière étape : la jointure avec la table « film ». « eq_ref » signifie qu’un seul enregistrement de la table « film » est lu pour chaque enregistrement correspondant de la table « film_actor ». Rien d’étonnant à cela puisque nous passons pour la table « film » par une clé primaire qui fait donc la jointure avec la clé primaire de « film_actor », on tombe donc directement sur un seul film identifié par sa clé primaire.

Bilan de cet EXPLAIN ?

L’estimation du nombres d’enregistrements à parcourir pour aboutir au résultat d’après l’optimiseur est de : 1 x 13 x 1 = 13 enregistrements. En parcourant rapidement cet EXPLAIN comme nous venons de le faire, on constate que 13 enregistrements environ sont à parcourir via deux covering index et une clé primaire : la requête a l’air convenable.

Les « Index hints » ou comment « orienter » les choix de l’optimiseur

Quel plan d’exécution l’optimiseur aurait-il choisi si nous n’avions pas eu d’index ? Quelles conséquences sur le nombre estimé d’enregistrements à parcourir ?

Pour le savoir, les barbares suppriment leurs index à grands coups de DROP INDEX ou d’ALTER TABLE plus ou moins heureux, les autres peuvent utiliser ce qu’on appelle les « index hints » et « suggérer » à l’optimiseur (pour ne pas dire forcer) d’effectuer certaines actions et pas d’autres.

Exemple : forcer l’utilisation d’un index ou au contraire l’ignorer ou encore joindre deux tables dans un ordre particulier…

Pour forcer le trait (« cas d’école » rappelez-vous), on supprime ici toute possibilité pour l’optimiseur d’utiliser un index « intéressant » pour lui :

mysql> EXPLAIN SELECT f.title
FROM film f IGNORE INDEX (PRIMARY, idx_title),
actor a IGNORE INDEX (PRIMARY, idx_actor_last_name), film_actor
fa IGNORE INDEX (PRIMARY, idx_fk_film_id)
WHERE a.actor_id = fa.actor_id
AND fa.film_id = f.film_id
AND a.last_name = ‘CRUZ’\G

*************************** 1. row
id: 1
select_type: SIMPLE
table: a
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 200
Extra: Using where
*************************** 2. row
id: 1
select_type: SIMPLE
table: fa
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 5920
Extra: Using where; Using join buffer
*************************** 3. row
id: 1
select_type: SIMPLE
table: f
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 952
Extra: Using where; Using join buffer
3 rows in set (0.00 sec)

Les résultats sont identiques en 5.1.26 et en 5.0.67, seule la mention du « Using join buffer » fait son apparition en 5.1
Le nombre approximatif d’enregistrements à parcourir est ici de : 200 x 5920 x 952 = 1 127 168 000, un résultat logique puisque l’intégralité des trois tables sont parcourues…

Bien que « dramatique » ce plan d’exécution a ici des conséquences très limitées puisque d’aussi petites tables sont aisément logées en mémoire. Les index sont stockés dans le key_buffer_size et le cache de l’OS s’occupe des données puisque nous sommes en MyISAM (à comparer avec l’innodb_buffer_pool qui stocke index ET données).

Résumons ce « cas d’école » : l’optimiseur a effectivement choisi des clés primaires (index le plus sélectif possible) ainsi qu’un index efficace, tout est logique.

Voyons maintenant un cas… « particulier » qui va nous apprendre à garder un oeil critique sur les plans d’exécution proposés par MySQL.

La légende des 30 %

Il était une fois un optimiseur MySQL qui décidait de ne jamais utiliser un index si celui-ci osait sélectionner plus de 30% des enregistrements d’une table. Pour schématiser, les développeurs de l’optimiseur considèreraient d’après leur expérience qu’en effet une fois cette limite dépassée, un parcours séquentiel de la table serait plus rapide que davantage d’accès aléatoires aux données (cas d’un index MyISAM par exemple). La réalité est évidemment beaucoup plus complexe et bien que le code source ne contienne pas en « dur » un tel seuil, cette valeur de 30% circule ici et là sur le net, davantage pour illustrer l’idée de sélectivité que pour réellement indiquer qu’il existe une telle valeur au sein de l’optimiseur qui guiderait ses choix si grossièrement.

L’idée à retenir est qu’un index sélectif est un bon candidat pour l’optimiseur et a donc toutes ses chances d’être retenu dans le plan d’exécution final.

Il existe cependant quelques exceptions, et il est parfois difficile de comprendre les choix de l’optimiseur…

Nous reprenons notre table de test conçue dans le billet précédent.
Rappel : 1 million d’enregistrements, 3 colonnes : une clé primaire, un TIMESTAMP et un champ « flag » (0 ou 1) équitablement réparti (environ 500 000 « 0″ pour autant de « 1″).

L’index « flag » ne possède que 2 entrées à comparer avec le million de rangées de la table t. Autrement dit, à un index correspond en moyenne 500 000 rangées possibles, bref absolument rien de sélectif, c’est tout le contraire.

Quel accueil l’optimiseur MySQL va t’il réserver à notre index « flag » sur une requête du type SELECT count(date) from t WHERE flag = 1 ?

Les tests effectués ci-dessous sont valables pour les versions 5.0.67 et la 5.1.26.
Rappel de la structure de la table t et de ses index :
mysql> show create table t; CREATE TABLE `t` ( `id` mediumint(8) unsigned NOT NULL auto_increment, `date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, `flag` tinyint(4) NOT NULL default '0', PRIMARY KEY (`id`), KEY `flag` (`flag`) ) ENGINE=MyISAM AUTO_INCREMENT=1000001 DEFAULT CHARSET=latin1
Concernant les index nous avons une clé primaire « id » et « flag », de type « index » :
mysql> show index from t\G *************************** 1. row Table: t Non_unique: 0 Key_name: PRIMARY Seq_in_index: 1 Column_name: id Collation: A Cardinality: 1000000 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: *************************** 2. row Table: t Non_unique: 1 Key_name: flag Seq_in_index: 1 Column_name: flag Collation: A Cardinality: 2 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment: 2 rows in set (0.01 sec)

Pour un rappel sur les différents types d'index disponibles, ce billet précédent est tout indiqué.
Appliquons notre requête à notre jeu d’essai :
mysql> SELECT SQL_NO_CACHE COUNT(date)
FROM t WHERE flag = 1; +-------------+ | count(date) | +-------------+ |      499959 | +-------------+ 1 row in set (1.70 sec)
Un score sensiblement identique est obtenu pour l’autre valeur de « flag » :
mysql> SELECT SQL_NO_CACHE COUNT(date)
FROM t WHERE flag = 0; +-------------+ | count(date) | +-------------+ |      500041 | +-------------+ 1 row in set (1.69 sec)
Voyons maintenant ce qui se passe avec EXPLAIN :
mysql> EXPLAIN SELECT SQL_NO_CACHE COUNT(date)
FROM t WHERE flag = 1\G *************************** 1. row id: 1 select_type: SIMPLE table: t type: ref possible_keys: flag key: flag key_len: 1 ref: const rows: 512463 Extra: 1 row in set (0.00 sec)
Surprise ! MySQL utilise notre index alors que la requête retourne environ la moitié de nos enregistrements… Nous sommes donc loin des « 30% », et pourtant les index ont été préférés au parcours complet de la table. On note ici le type « ref » qui signifie que chaque ligne de la table t correspondant à la valeur de « flag » est lue, c’est à dire environ 500 000 random I/O.

Retenons que sans la clause EXPLAIN, cette requête s’exécute en 1.7 secondes quel que soit la valeur de flag.

Un index de trop ?

Voyons ce que cette même requête donnerait sans l’index appliqué au champ « flag » :
mysql> EXPLAIN SELECT SQL_NO_CACHE count(date)
FROM t IGNORE INDEX(flag)
WHERE flag = 1\G
*************************** 1. row
id: 1
select_type: SIMPLE
table: t
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000000
Extra: Using where
1 row in set (0.00 sec)

Changement de décor, MySQL ne peut plus utiliser l’index « flag » et effectue un scan complet de la table, un million de lignes sont parcourues (deux fois plus qu’avec l’utilisation de l’index « flag ») mais séquentiellement cette fois.

Quel est le temps d’exécution de ce scan complet ?
mysql> SELECT SQL_NO_CACHE COUNT(date)
FROM t IGNORE INDEX(flag) WHERE flag = 1\G *************************** 1. row count(date): 499959 1 row in set (0.23 sec)
23 centièmes de seconde seulement, le scan complet de la table est donc ici 7 fois plus rapide que l’accès aux données par les index.

Pourquoi l’optimiseur a t’il décidé de partir sur un plan d’exécution basé sur l’utilisation de l’index « flag » si peu sélectif ? Peut-être considère t-il que 50% des données retournées est un seuil trop bas pour « désactiver » les index par rapport au scan complet de la table ?

Modifions maintenant la distributivité du champ flag. Nous avions quasiment autant de 0 que de 1 dans la colonne « flag », voyons ce que donnerait 95% de « 1″ et 5% de « 0″.

Pour cela on modifie la procédure stockée utilisée précedemment pour le remplissage de la table « t » et en deux étapes on charge d’abord les 950 000 lignes de « 1″ puis les 50 000 lignes de « 0″, reste alors à mélanger le tout :
mysql> CREATE TABLE t2 LIKE t; Query OK, 0 rows affected (0.03 sec) mysql> INSERT INTO t2 SELECT * FROM t ORDER BY RAND(); Query OK, 1000000 rows affected (12.59 sec) Records: 1000000 Duplicates: 0 Warnings: 0
t2 est désormais équivalente à la table t à ceci près qu’elle contient 95% de « 0″, le reste en « 1″, le tout aléatoirement réparti.
mysql> EXPLAIN SELECT COUNT(date)
FROM t2 WHERE flag = 1\G *************************** 1. row id: 1 select_type: SIMPLE table: t2 type: ref possible_keys: flag key: flag key_len: 1 ref: const rows: 950277 Extra: 1 row in set (0.01 sec)
Même résultat que précédemment, quelque soit la valeur de flag, « 1″ ou « 0″ : MySQL passe toujours par l’index s’il est disponible :
mysql> select COUNT(date)FROM t2
WHERE flag = 0; +-------------+ | count(date) | +-------------+ |       50000 | +-------------+ 1 row in set (0.23 sec) mysql> selectCOUNT(date) FROM t2 IGNORE INDEX(flag) WHERE flag = 0; +-------------+ | count(date) | +-------------+ |       50000 | +-------------+ 1 row in set (0.17 sec) mysql> selectCOUNT(date) FROM t2
WHERE flag = 1; +-------------+ | count(date) | +-------------+ |      950000 | +-------------+ 1 row in set (3.17 sec) mysql> selectCOUNT(date) FROM t2 IGNORE INDEX(flag)
WHERE flag = 1; +-------------+ | count(date) | +-------------+ |      950000 | +-------------+ 1 row in set (0.20 sec)
… On constate que les résultats sont quasiment équivalents pour le cas où flag = 0, c’est effectivement la valeur pour laquelle l’index est le plus sélectif, en revanche l’écart se creuse encore davantage entre le scan complet de la table et l’accès aux données via l’index : le parcours complet de la table est 16 fois plus rapide.

La sélectivité de notre index est la même dans la table t2 que dans la table t1, seule la distributivité des données de la colonne flag a été modifiée pour en faire un index vraiment peu sélectif dans le cas où « flag » = 1 puisque dans cette configuration ce sont 95% des données de la table qui sont sélectionnées, la légende prend un coup de vieux…

Conclusion

Il est parfois difficile de comprendre les choix de l’optimiseur, il existe des règles générales et des exceptions troublantes. L’optimiseur est un logiciel complexe, très efficace la plupart du temps mais pas parfait. L’architecture même de MySQL, basé sur des moteurs « externes » (« pluggable storage engine »), complique sa tâche : il lui est difficile, selon les cas, de déterminer où seront stockées les données. Cette information est pourtant cruciale pour prendre des décisions lourdes de conséquences. De plus chaque moteur gère les index à sa façon…
Sommes-nous en présence de MyISAM (index en mémoire, données cachées par l’OS), sur du InnoDB ? (index clustered, données triées selon la clé primaire « accolées » à l’index), ou bien encore sur du MEMORY (les lectures aléatoires ou random I/O sont beaucoup moins coûteuses en mémoire que sur disque), les différents système de cache sont-ils activés ? Les données sont-elles toutes en mémoire ou en partie sur disque ? On peut également parier sur le fait que l’apparition des disques SSD devrait par exemple impacter les choix de l’optimiseur à l’avenir…

Bref, à moins d’avoir écrit soi-même le code source de l’optimiseur, il est difficile de tout maîtriser de A à Z en ce qui le concerne, le conseil est alors le suivant : il faut appliquer régulièrement EXPLAIN sur les requêtes importantes de vos applications. Savoir lire un plan d’exécution et ainsi comprendre ce que MySQL a decidé pour votre requête permet de détecter avec un peu d’expérience si le plan d’exécution est efficace.
Utilisez le cas échéant les « index hints » pour modifier si besoin le parcours proposé : IGNORE INDEX, FORCE INDEX, ou encore STRAIGHT JOIN si vous souhaitez modifier l’ordre de jointures de vos tables…

Sans se focaliser sur les fameux 30%, un index sélectif est un bon candidat. Nous avons rencontré un cas où un parcours total de la table aurait été plus efficace, cependant c’est parfois l’inverse qui se produit, un index même peu sélectif peut s’avérer payant, il faut donc tester si le plan d’exécution proposé vous semble perfectible.

Derniers détails d’importance : on ne peut pas comparer uniquement deux plans d’exécution uniquement sur l’estimation du nombre d’enregistrements à parcourir… La preuve dans notre exemple, le parcours total et séquentiel de la table (1 million d’enregistrement) s’avère plus rapide que les 500 000 accès aléatoires issus de l’index. On retiendra également de notre exemple qu’un index n’est pas systématiquement synonyme de meilleures performances… (Même si c’est le cas en général).

L’exemple étudié ici est un cas particulier au sens où c’est plutôt le parcours complet de la table (full scan) que l’on cherche d’habitude à éviter. Sachez qu’il existe une variable serveur, max_seeks_for_key (on en parle aussi ici et là) sur laquelle il est possible de jouer pour orienter les choix de l’optimiseur.

Enfin, puisqu’il est difficile d’aborder toutes les problématiques possibles autour de la sélectivité d’un index dans un seul billet, voici quelques autres articles sur la même thématique afin d’aller encore plus loin :

L’article qui m’a incité à effectuer mes propres tests.

Une excellente illustration des difficultés parfois rencontrées par l’optimiseur, un coup de pouce du DBA permet alors de réduire la requête de 2.5 jours à 1h !
Un court article de Farhan Mashraqi sur la sélectivité.
Arjen’s journal sur l’utilité d’un index

Une belle formule issue du manuel MySQL : Comment estimer l’efficacité d’une requête ?

N’oubliez pas de lire également les commentaires associés à ces articles…

Générer un jeu de données : shell, mysqlslap, et procédure stockée

arnaud — Mon, 18 Aug 2008 22:39:46 +0000

Le prochain article de notre série consacrée aux index MySQL approche et j’ai besoin pour ce prochain épisode de générer une table de test de la forme suivante :

CREATE TABLE `t` ( `id` mediumint(8) unsigned NOT NULL auto_increment, `date` timestamp NOT NULL, `flag` tinyint(4) NOT NULL default '0', PRIMARY KEY (`id`), KEY `flag` (`flag`) ) ENGINE=MyISAM;

La structure est définie, reste à alimenter la table, disons 1 million d’enregistrements.

La valeur du champ « flag » est importante pour nos tests ultérieurs, sa valeur doit pour le moment être comprise entre 0 et 1, le tout à peu près uniformément distribué.

La requête sera la suivante :

INSERT INTO test.t (flag) VALUES (ROUND(RAND()));

Il faut maintenant exécuter celle-ci 1 million de fois.
Voyons ce que cela donne en utilisant le shell, mysqlslap ou bien encore une procédure stockée.

Le shell

L’idée : générer un fichier texte des données à insérer puis exécuter le fichier de sortie comme entrée du client mysql.

Cette méthode n’est pas la plus efficace du lot, surtout pour 1 million de lignes, mais on peut néanmoins arriver à ses fins :

debian:/tmp# (for i in `seq 1 1000000`; do echo "insert into test.t(flag) values(round(rand()));"; done;) > /tmp/insertions.txt

Puis :

debian:/tmp# mysql test < /tmp/insertions.txt

Notre million de lignes est inséré.

mysqlslap

mysqlslap est un outil de benchmark que nous avons étudié récemment. Nous détournons ici son utilisation première pour finalement exécuter notre million de requêtes :

debian:/usr/local/mysql51# ./bin/mysqlslap --user=root --socket=/tmp/mysql.sock --concurrency=1 --iterations=1000000 --query="insert into test.t (flag) values (round(rand()))"

Benchmark
Average number of seconds to run all queries: 0.000 seconds
Minimum number of seconds to run all queries: 0.000 seconds
Maximum number of seconds to run all queries: 0.609 seconds
Number of clients running queries: 1
Average number of queries per client: 1

Cette solution est plus rapide que la précédente, aussi si vous disposez de mysqlslap, n’hésitez pas.

La procédure stockée : REPEAT… UNTIL

Dès lors qu’on envisage d’insérer 1 million de lignes dans une table, la notion de « boucle » n’est jamais très loin, et finalement la procédure stockée non plus. Celle-ci est en effet un moyen simple et rapide d’implémenter un traitement répétitif.

Basique et à peine paramétrable (seul le nombre d’enregistrements à insérer est dynamique), voici à quoi ressemble la procédure stockée permettant d’insérer notre million de lignes :

delimiter // CREATE PROCEDURE fill_table(nb_rows INT) BEGIN DECLARE i INT DEFAULT 0; REPEAT SET i = i + 1; INSERT INTO t (flag) VALUES(round(rand())); UNTIL i >= nb_rows END REPEAT; END; // delimiter ;

Pas vraiment besoin de commenter le code, on note simplement les « delimiter » qui permettent de définir une autre terminaison que « ; » le temps d’écrire la procédure dans le client mysql.

Pour appeler celle-ci :

mysql> CALL fill_table(1000000);
Query OK, 1 row affected (1 min 37.98 sec)

Cette solution est la plus rapide des trois présentées ici.

Mission accomplie ? Presque…

Avant de lancer la procédure stockée, la commande SHOW INDEX affichait une cardinalité de 0 pour la clé primaire et de NULL pour notre index situé sur « flag ».

Une fois la procédure terminée, un SHOW INDEX indique cette fois une cardinalité mise à jour pour la clé primaire (1 000 000) mais celle-ci est toujours à NULL pour l’index « flag ».

La commande ANALYZE permet de laver cet affront :

Les statistiques de notre index sont désormais à jour et la commande SHOW INDEX indique désormais une cardinalité de 2 pour l’index « flag », le champ indexé ne comporte effectivement que des 0 ou des 1.

Nous voilà face à un index de cardinalité 2… Peu sélectif ? Inutile ? Mieux que rien ? Les paris sont ouverts.

Réponse au prochain numéro, stay tuned.