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 :

mysql> show variables like ‘innodb_buffer_pool_size’;
+————————-+———+
| Variable_name           | Value   |
+————————-+———+
| innodb_buffer_pool_size | 8 388 608
+————————-+———+

… le jour et la nuit avec :

mysql> show variables like ‘innodb_buffer_pool_size’;
+————————-+————+
| Variable_name           | Value      |
+————————-+————+
| innodb_buffer_pool_size | 3 984 588 800
+————————-+————+

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.

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

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

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> select COUNT(date) FROM t2 IGNORE INDEX(flag) WHERE flag = 0;
+-------------+
| count(date) |
+-------------+
|       50000 |
+-------------+
1 row in set (0.17 sec)

mysql> select COUNT(date) FROM t2
WHERE flag = 1;
+-------------+
| count(date) |
+-------------+
|      950000 |
+-------------+
1 row in set (3.17 sec)

mysql> select COUNT(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…

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 :

mysql> ANALYZE TABLE t;
+---------+---------+----------+----------+
| Table   | Op      | Msg_type | Msg_text |
+---------+---------+----------+----------+
| world.t | analyze | status   | OK       |
+---------+---------+----------+----------+

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.

Trois semaines d’attente, cela mérite un billet digne de ce nom, c’est parti.

Indexer, pourquoi ?

L’indexation peut avoir plusieurs buts :
- Accéder à ses données plus rapidement, les index sont en effet l’outil le plus puissant pour accélérer les temps d’exécution de vos requêtes jusqu’à parfois plusieurs centaines de % !
- Définir le degré d’unicité d’une colonne donnée : chaque champ doit-il être unique ? les doublons sont-ils autorisés ?

Principe de fonctionnement

Lorsque vous envoyez une requête à votre serveur MySQL, celle-ci est d’abord confiée au « parseur » SQL qui a pour but de vérifier si la syntaxe de votre demande est correcte. Cette étape franchie, la requête passe par « l’optimiseur ». Il s’agit ici de déterminer le plan d’exécution de la requête afin que celle-ci s’exécute le plus rapidement possible.

L’optimiseur détecte si d’éventuels index sont disponibles, si c’est le cas il décidera de s’en servir… ou pas : il est parfois plus rapide de ne pas se servir d’un index ! Nous verrons pourquoi au cours de cette série d’articles.

Une fois le plan d’exécution achevé, c’est le moteur de stockage qui prend le relais, celui-ci peut être vu comme un « module » de MySQL :

Pour schématiser, et dans un monde idéal, lorsqu’un index est disponible et « compatible » avec votre requête, l’optimiseur MySQL peut décider de l’utiliser afin d’éviter de parcourir l’ensemble des données des tables concernées.

Un exemple couramment employé pour illustrer ce propos consiste à imaginer la difficultée que nous aurions à retrouver quelqu’un dans l’annuaire si nous connaissions son nom mais pas l’alphabet (qui est notre index)… Transposé au monde informatique cela donne un serveur MySQL qui compare une à une les entrées du botin pour trouver toutes celles qui correspondent au nom recherché. Si au contraire ce nom est indexé, et si celui-ci commence par exemple par ‘T’, le serveur sait directement qu’il doit démarrer sa recherche à partir du ‘T’. Imaginez l’impact en terme de gain de temps lorsque plusieurs jointures sont concernées : deux tables de 10 000 lignes chacune forment un produit cartésien de 100 000 000 lignes environ à étudier…

Les index n’ont hélas pas que des avantages :
- Les opérations de mises à jour (INSERT, UPDATE, DELETE) sont en effet ralenties puisqu’en plus des données, les index doivent eux aussi être mis à jour lors de ces opérations, c’est le prix à payer… Ce prix peut néamoins se « négocier », nous verrons cela plus tard.

Notre terrain de jeu, la base « world »

MySQL propose au téléchargement plusieurs bases d’exemple dont « world » et « sakila ». Elles épargnent le soin aux utilisateurs de MySQL souhaitant tester quelques requêtes de se constituer eux-mêmes une base de test, celles-ci sont prêtes à l’emploi.

Nous utiliserons pour nos tests la base « world ». Très simple puisque constituée uniquement de trois petites tables MyISAM (Country, CountryLanguage et City), elle permet de se concentrer uniquement sur les index sans perdre de temps à assimiler un schéma plus complexe.

Si vous souhaitez transformer le script de création SQL de la base « world » en une version graphique « presque » MCD (les relations entre les tables ne sont pas générées automatiquement pour cette base), le billet précédent est fait pour vous, les étapes d’installation et de génération du MCD par « reverse engineering » avec DBDesigner 4 y sont décrites.

Voici ce qu’on peut obtenir pour cette base à partir de DBDesigner :

Quel type d’index choisir : PRIMARY KEY, UNIQUE, ou INDEX ?

Choisissez le type de vos index avec soin :
- Une clé primaire (PRIMARY KEY) est strictement unique, les NULL ne sont pas autorisés.
- Un index de type UNIQUE est comparable à une clé primaire, mis à part pour les valeurs NULL puisque celles-ci sont autorisées (et potentiellement en plusieurs occurences).
- Un index de type INDEX ou KEY (c’est un alias) signifie simplement que l’on souhaite indexer une colonne susceptible de contenir des doublons.

Les index de type FULLTEXT et SPATIAL sont particuliers et méritent un épisode à eux seuls, ils seront donc évoqués ultérieurement.

Passons rapidement sur l’étape de déclaration d’un index, celle-ci s’effectue soit au moment de la création de la table, soit plus tard comme ici :

mysql> CREATE INDEX idx_district ON City (District);
Query OK, 4079 rows affected (0.04 sec)
Records: 4079  Duplicates: 0  Warnings: 0

Nous venons de créer un index de type INDEX (autorise les doublons) sur la colonne District de la table City.

Attention, si nous avions tenté la même chose avec un index de type UNIQUE…

mysql> CREATE UNIQUE INDEX idx_district ON City (District);
ERROR 1062 (23000): Duplicate entry 'Zuid-Holland' for key 2

… MySQL nous signale qu’il y’a déjà des doublons dans la colonne District, impossible donc de créer un index de type UNIQUE sur celle-ci.

Pour supprimer cet index :
mysql> DROP INDEX idx_district ON City;
Ou :
mysql> ALTER TABLE City DROP INDEX idx_district;

Pour visualiser les index d’une table :

mysql> SHOW INDEX FROM Country;

Attention aux doublons !

Inutile de rajouter un index de type « INDEX » ou encore « UNIQUE » sur un champ qui est déjà clé primaire par exemple… Vous dupliqueriez inutilement les index avec à la clé un gaspillage d’espace disque/mémoire, des ralentissements inutiles lors des mises à jour, davantage de travail pour l’optimiseur…

Quels types de champ indexer ?

INT, VARCHAR, BLOB… ? Quels sont les meilleurs candidats à l’indexation ?

Plus l’index est court, mieux c’est : un index est en permanence comparé à d’autres valeurs (celles recherchées), ces comparaisons sont plus rapides si la zone à comparer est plus courte. Des index concis occupent également moins de place sur disque, génèrent moins d’I/O (activité disque s’ils ne sont pas en mémoire) et peuvent ainsi être stockés en plus grand nombre dans une même quantité de RAM (pensez au key_buffer_size de MyISAM par exemple).

Bref, si vous désirez stocker une liste de noms de villes sous forme de chaînes de caractères, sachez qu’il est inutile de réserver un champ de type CHAR(255) : rares sont celles qui atteindront cette longueur, pensez plutôt au VARCHAR qui s’adaptera à la longueur de vos valeurs.
Plus malin encore, lors de la conception de votre base de données, intéressez-vous aux différentes formes de normalisation : 1NF, 2NF, 3NF, ces méthodes permettent d’obtenir un schéma qui permet de partir sur de bonnes bases.
En gardant cet exemple des villes, si vous stockez dans une table « inscrits » toutes les infos contextuelles à un utilisateur, dont sa ville, envisagez de stocker dans une table « ville », toutes les infos qui s’y rapportent : nom, population, etc. Reliez ensuite votre table « inscrits » à la table « ville » par la valeur de la clé primaire de ville et vous supprimerez ainsi tous ces libellés de villes identiques au profit d’un ID bien plus rapide et économique.

Soyez radins !

Vos index seront d’autant plus efficaces s’ils sont apposés sur des champs bien adaptés à vos données. Ne gaspillez pas le capital « performance » de vos index en utilisant un INT pour stocker par exemple la vitesse légale sur autoroute en France (par temps sec) : 130 km/h…  Un TINY INT UNSIGNED suffira (permet de stocker les valeurs de 0 à 255). Un INT permet lui de stocker des valeurs comprises entre -2.147.483.648 2.147.483.647, et en rajoutant l'attribut UNSIGNED, on obtient un rayon d’action de 0 à plus de 4 milliards ! A quoi bon utiliser un INT dans cet exemple ? Quand on sait de plus qu’un INT occupe quatre fois plus de place qu’un TINY INT, l’impact sur les performances et la perte d’espace avec une table de plusieurs millions d’enregistrements est évident…

Prenez connaissance des caractéristiques des types de données que vous utilisez. Visualisez également la taille requise, c’est un élement qui peut s’avérer dissuasif.

Pour résumer, n’indexez pas une colonne en fonction de son type, mais prenez soin dans un premier temps de définir celles-ci avec le type de données qui leur convient le mieux, le plus économique. Prévoyez une marge néanmoins : n’utilisez pas un TINY INT même UNSIGNED pour un identifiant de clé primaire AUTO_INCREMENT concernant une newsletter d’un grand service commercial : si tout se passe bien vous devriez rapidement dépasser le seuil des 255 inscrits… Le type de données juste « au-dessus », SMALLINT UNSIGNED, qui permet d’aller jusqu’à 65535, est sans doute plus confortable.

Le tips dbnewz : utilisez la commande PROCEDURE ANALYSE()

Cette commande analyse pour vous vos tables et vous propose le type idéal pour vos données… si vous en avez bien sûr, ça ne peut pas vous aider lors d’une création de table. En revanche, elle permet « d’auditer » vos enregistrements actuels, d’en tirer quelques statistiques et propose le type le plus adapté :

mysql> SELECT Name FROM Country PROCEDURE ANALYSE(10,256)\G
Field_name: world.Country.Name
Min_value: Afghanistan
Max_value: Zimbabwe
Min_length: 4
Max_length: 44
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 10.0962
Std: NULL
Optimal_fieldtype: VARCHAR(44) NOT NULL
1 row in set (0.00 sec)

Vous pouvez bien sûr effectuer cette requête sur l’intégralité des champs de l’une de vos tables (SELECT *…)
Les paramètres fournis à PROCEDURE ANALYSE () sont à modifier en fonction de vos souhaits. Par défaut cette fonction a tendance à vouloir transformer toutes vos chaînes de caractères en champs ENUM (stockés sous forme numérique en interne), à vous de définir combien de champs ENUM vous êtes prêts à utiliser. Réservez-les pour les cas où le champ représente une courte liste « fermée », ex « M » ou « F », les jours de la semaine par exemple, etc.

Où placer ses index : quels sont les champs à indexer ?

Les champs concernés par une clause WHERE, ORDER BY, GROUP BY, MIN(), MAX(), ainsi que les champs qui permettent de relier des tables entre elles, sont de bons candidats à l’indexation, exemple :

SELECT ci.Name, ci.Population
FROM City ci INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE ci.Population > 5000000
ORDER BY ci.District ASC LIMIT 3

- Le champ CountryCode de la table City ainsi que le champ Code de la table Country sont tous les deux à indexer. C’est d’ailleurs le cas ici puisque ces deux champs sont respectivement clés primaires de la table City et Country.
- Le champ Population est intéressant à indexer, il permet à MySQL de parcourir très rapidement les villes par leur population triée et évite de comparer l’intégralité des populations de chaque ville, une à une.
- Le champ District est également un candidat à l’indexation, il peut aider MySQL à trier les données plus rapidement.

A retenir : on indexe en priorité les champs impliqués dans les clauses évoqués ci-dessus (en gras), pas forcément ceux présents dans le SELECT.

Les index composés (ou multiples) et la règle du leftmost prefixing

« Faut-il préférer un index unique ou composé » était l’une des questions posées par l’un d’entre vous il y’a quelques semaines…

Un index composé doit se construire en fonction des requêtes que vous effectuez sur la table concernée.
Prenons pour exemple la table City et ses cinq champs (ID, Name, CountryCode, District, Population).

Si les seules requêtes que vous avez sur City sont du type :

SELECT ... FROM City WHERE Name = "..."

… Indexez Name et tout ira bien.

Si en revanche il vous arrive de trier non seulement sur « Name » mais également sur le code du pays :

SELECT ... FROM City WHERE Name = "..." AND CountryCode = "..."

Dans ce cas, plutôt que de laisser MySQL comparer tous les CountryCode de la table avec votre recherche (ex : « FRA »), indexez la colonne CountryCode… Oui mais pas toute seule !
Considérez en effet pour l’instant que MySQL n’utilise qu’un index par table, l’optimiseur MySQL choisit donc le plus restrictif afin que votre requête s’exécute le plus rapidement possible (nous verrons plus tard les cas particuliers où MySQL peut tirer parti de plusieurs index).
Conséquence, il vous faut trouver un index qui soit utilisable pour vos deux critères de recherche : « Name » et « CountryCode ». La solution : créez un index multiple sur ces deux champs.

Dès lors que vous utilisez un index multiple, la règle du leftmost prefixing rentre en jeu. Trop souvent méconnue, elle permet pourtant de créer ses index de façon efficace et d’éviter les doublons.

Afin d’illustrer cette règle, ajoutons cette fois à la table City un index multiple sur les champs Name, CountryCode, District et Population :

mysql> CREATE INDEX name_cc_dis_pop ON City (Name, CountryCode, District, Population);

Voici ce que l’on obtient avec le SHOW INDEX correspondant (la clé primaire existait déjà à la création de la table, ci-dessous une vue partielle des résultats réels) :

mysql> SHOW INDEX FROM City;


| Key_name | Seq_in_index | Column_name
+-------+------------+-----------------+

|name_cc_dis_pop |   1 |  Name

|name_cc_dis_pop |   2 | CountryCode

|name_cc_dis_pop |   3 | District

|name_cc_dis_pop |   4 | Population | 
+-------+------------+-----------------+

On remarque par rapport au SHOW INDEX précédent que cette fois-ci nous avons la colonne « Seq_in_index » qui s’incrémente pour chaque colonne qui compose notre index multiple. La position de chaque index dans cette séquence a une importance, c’est ce que nous allons voir maintenant.

Tel quel, cet index multiple sera potentiellement utilisé pour les requêtes de ce type :

SELECT ... FROM City WHERE Name = ... AND CountryCode = ... AND District = ... AND Population = ...
SELECT ... FROM City WHERE Name = ... AND CountryCode = ... AND District = ...
SELECT ... FROM City WHERE Name = ... AND CountryCode = ...
SELECT ... FROM City WHERE Name = ...

Une fois cette « logique » acquise, on comprend qu’il est inutile de rajouter un index sur Name par exemple puisque cette colonne est déjà indexée grâce à cet index multiple. Idem pour notre exemple précédent  d’index multiple concernant les champs Name et CountryCode, là encore inutile de recréer un index sur ces deux champs puisque ces derniers sont déjà représentés dans notre dernier exemple.

En revanche, si l’ordre de vos champs ne respecte pas l’ordre de séquence de votre index, comme ici :

SELECT ... FROM City WHERE Name = ... AND Population = ..

Cette requête ne bénéficiera pas complètement de l’index multiple précedemment crée, cela dit l’optimiseur tirera sûrement parti de cet index pour la colonne Name, mais pas pour le second critère de recherche.

De même si votre requête est du type :

SELECT ... FROM City WHERE CountryCode = ...
SELECT ... FROM City WHERE District = ...
SELECT ... FROM City WHERE Population = ...
SELECT ... FROM City WHERE CountryCode = ... AND District = ... AND Population = ...

… et autres variations qui ne débutent pas avec « Name » et ne respectent pas ensuite l’ordre de séquence de l’index (Name, CountryCode, District, et Population), l’index ne sera pas utilisé.

En conséquence, il est donc tout à fait légitime d’indexer par ailleurs la colonne Population seule si vous avez des requêtes du type :

SELECT ... FROM City WHERE Population > ...

Mesurez l’efficacité des index avec EXPLAIN

Impossible d’évoquer les index sans parler de la commande EXPLAIN. Absolument fondamentale, elle affiche le plan d’exécution décidé par l’optimiseur MySQL et vous permet de mesurer si oui ou non vos index sont réellement utilisés.

Reprenons une des premières requêtes de ce billet et rajoutons-lui le mot clé EXPLAIN :
(on considère ici que la table City ne contient que sa clé primaire, pas les index rajoutés précedemment)

mysql> EXPLAIN SELECT ci.Name, ci.Population
FROM City ci INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE ci.Population > 5000000
ORDER BY ci.District ASC LIMIT 3\G


*************************** 1. row *************
id: 1
select_type: SIMPLE
table: ci
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra: Using where; Using filesort
*************************** 2. row *************
id: 1
select_type: SIMPLE
table: co
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: world.ci.CountryCode
rows: 1
Extra: Using index
2 rows in set (0.00 sec)

La commande EXPLAIN sera étudiée plus précisemment dans un autre épisode, pour le moment contentons-nous de prêter attention aux champs en gras :

- Sur la première ligne le type ALL signale que MySQL doit effectuer un « full table scan » c’est à dire parcourir entièrement la table City qui compte 4079 enregistrements, ceci afin de repérer quelles sont les villes qui ont une population supérieure à 5M d’habitants. Aucun index/key n’a pu être utilisé (possible_keys : NULL) pour résoudre cette partie de la requête. La colonne « rows » indique le nombre approximatif d’enregistrements que MySQL pense devoir analyser pour mener à bien l’opération.

- La seconde ligne nous indique que cette fois MySQL a un candidat pour l’indexation, il s’agit de la clé primaire de la table Country, la jointure s’effectuant avec le champ « CountryCode » de la table City, qui est également une clé primaire. Résultat : MySQL effectue la correspondance très rapidement (rows : 1 et extra : Using index).

Ceci répond à une des questions posées précedemment par un lecteur : « Quand préférer le FULL TABLE SCAN à l’index ? » C’est en fait le travail de l’optimiseur, il doit déterminer si oui ou non un index vous fera gagner du temps. Il se peut qu’il se trompe (rarement), nous verrons comment orienter ses choix si besoin.

Rajoutons maintenant un index de type « INDEX » sur la colonne Population :

mysql> CREATE INDEX idx_pop ON City (Population);

Puis appliquons à nouveau la même commande EXPLAIN, on obtient cette fois :

*************************** 1. row ************
id: 1
select_type: SIMPLE
table: ci
type: range
possible_keys: idx_pop
key: idx_pop
key_len: 4
ref: NULL
rows: 25
Extra: Using where; Using filesort
*************************** 2. row ************
id: 1
select_type: SIMPLE
table: co
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: world.ci.CountryCode
rows: 1
Extra: Using index
2 rows in set (0.02 sec)

Notre index a permis à MySQL de lire 160 fois moins de lignes cette fois-ci par rapport à l’exemple précédent… Seules 25 lignes de la table City sont lues désormais (au lieu des 4079 lignes précedemment parcourues). C’est un gain très intéressant en termes de ressources serveur ! Amateurs de chiffres, des benchmarks sont prévus dans la suite de cette série.

Afin de patienter jusqu’aux prochains épisodes justement, vous pouvez commencer par appliquer les quelques conseils de ce billet tout en relisant pourquoi pas l’article concernant l’implémentation des index (BTREE ou HASH) selon le type de votre moteur de stockage (MyISAM, InnoDB ou MEMORY).

Il reste certaines de vos questions en suspens, elles ne sont pas oubliées et seront débattues ici très prochainement.

Si vous avez des questions ou des remarques concernant cette première étape, n’hésitez pas.

Afin que les choses soient claires pour tout le monde, je vous propose en fait de participer à la conception du sommaire de la future série d’articles sur les index qui sera publiée prochainement sur dbnewz.

L’indexation est en effet un thème auquel il faut absolument s’intéresser, tout d’abord pour éviter des catastrophes et bien sûr pour optimiser les performances !

Les index sont une arme redoutable, à double tranchant : oubliez-les et ils se rappeleront violemment à votre bon souvenir « ça ne fait pas 5 min que nous sommes en production et la base ne répond plus, la sonde cpu est à 100%, on ne peut même plus se connecter à la base (too many connections), qu’est ce qui se passe ?! » Dans le même genre d’extrêmes, invitez-les partout et vous compliquerez la tâche de l’optimiseur MySQL (chargé de concevoir le meilleur plan d’exécution possible pour vos requêtes), ralentirez vos mises à jour et augmenterez la taille de vos bases de données, générant d’autres problèmes…
En revanche, une bonne stratégie d’indexation permet parfois d’obtenir des gains en performance très importants, parmi les plus importants qu’on puisse obtenir en agissant sur les réglages d’une configuration MySQL « classique ».

Ce que je vous propose donc, c’est non pas de m’envoyer des copies de vos plans d’exécution ou les schémas de vos tables, mais plutôt de poster ici vos attentes, les zones d’ombre que vous souhaiteriez éclaircir concernant les index.
Exemples :
« Pourquoi un index disponible n’est pas pris en compte ? »
« En quoi indexer peut améliorer les performances ? »
« Quels sont les champs à indexer ? », etc, etc.

Profitez de l’occasion qui vous est donnée pour poster dans les commentaires de ce billet vos problématiques, vos souhaits, j’en tiendrai compte lors de la conception des différents chapitres que comportera cette série qui deviendra du « cousu main » pour tous les participants, intéressant non ?

A vos claviers

Ce choix n’est en effet pas toujours disponible, c’est même plutôt rare puisque seul le moteur de stockage MEMORY vous permet depuis la version 4.1 de MySQL, d’effectuer ce choix. Nous ne parlerons pas ici du MySQL Cluster et de son moteur NDB qui sera abordé spécifiquement dans un autre épisode.

Pourquoi alors se soucier de ce type d’implémentation si seul le moteur MEMORY offre la possibilité de choisir ?
- MyISAM et InnoDB pourraient à l’avenir proposer ce choix.
- Afin de comprendre plus finement comment fonctionnent les index que vous utilisez tous les jours, se pencher sur la façon dont ils sont implémentés permet de mieux appréhender certains résultats.

L’index B-TREE

Star incontestée de l’implémentation de nos index sous MySQL, l’index B-TREE est partout. Et pour cause : c’est la seule implémentation disponible sous MyISAM et InnoDB, vos index sont donc systématiquement stockés sous forme de B-TREE si vos tables sont issues d’un de ces moteurs de stockage.

« Soient L et U deux entiers naturels non nuls tels que L ≤ U. On définit alors un L-U arbre B [...]« , … C’est exact, il y’a plusieurs façons d’expliquer le fonctionnement d’un index B-TREE, les formules mathématiques en sont une et wikipédia s’en chargeant très bien, je ne vais donc pas recopier les formules mathématiques ici mais vous proposer plutôt un schéma :

Ce schéma est en fait issu d’une animation (essayez-là), cette applet java permet d’appréhender de façon presque ludique le fonctionnement du B-TREE. Amusez-vous à insérer des données et à prédire leur destination finale. Une fois que vous vous sentez à l’aise en insertion, testez le mode suppression et dites bonjour à la récursivité…

En deux mots, un B-TREE est un arbre équilibré (cette notion se perçoit bien visuellement), dont les données sont triées. A la base se trouve une racine de laquelle partent des noeuds qui se divisent ou fusionnent selon les données insérées. Chaque noeud a plusieurs clés ou valeurs, ce qui permet de diminuer la complexité de l’arbre et réduit la nécessité d’équilibrage (répartition des données).

Si les index B-TREE sont choisis par défaut pour les deux moteurs les plus utilisés, MyISAM et InnoDB, ça n’est pas par hasard. Polyvalents, les index B-TREE permettent d’effectuer un vaste choix de comparaisons. Tous les opérateurs suivants sont autorisés : =, >, >=, <, <=, la commande SQL « BETWEEN » se rajoutant à cette liste.

Les valeurs extrèmes des noeuds peuvent être considérées comme des bornes qui déterminent l’emplacement potentiel d’une clé recherchée ou à insérer.

Le HASH index

Contrairement aux moteurs MyISAM et InnoDB, le moteur MEMORY utilise par défaut une implémentation de type HASH. Cela ne veut pas dire que vous ne pouvez pas créer de B-TREE pour autant pour une colonne en particulier :

mysql> create table essai (id1 int, id2 int, unique using hash (id1), unique using btree (id2)) engine = memory;
Query OK, 0 rows affected (0.05 sec)

mysql> show create table essai;
----------------------------------+
| Table | Create Table
----------------------------------+
| essai | CREATE TABLE `essai` (
`id1` int(11) default NULL,
`id2` int(11) default NULL,
UNIQUE KEY `id1` USING HASH (`id1`),
UNIQUE KEY `id2` USING BTREE (`id2`)
) ENGINE=MEMORY DEFAULT CHARSET=latin1

Quel est le principe de fonctionnement d’un index de type HASH ? Encore une fois, un schéma permet de se fixer les idées :

Issu de l’article consacré aux tables de hachage sur wikipedia, il permet de bien comprendre ce qui se passe.

On observe sur ce schéma que lors d’une recherche une fonction de hachage est appliquée sur la clé, ici « John Smith ». Une fois hachée, cette chaîne de caractères devient un index qui pointe vers la donnée recherchée (le numéro de téléphone).
A noter : les données ne sont pas ordonnées.

Conséquence de ce mécanisme, les index HASH permettent uniquement les comparaisons d’égalité effectuées via les opérateurs « = » ou « <=> ». Rappelons que « <=> » permet de considérer la valeur NULL comme une valeur « normale », exemple :

mysql> select NULL = NULL;
+-------------+
| NULL = NULL |
+-------------+
| NULL |
+-------------+
1 row in set (0.00 sec)

mysql> select NULL <=> NULL;
+---------------+
| NULL <=> NULL |
+---------------+
| 1 |
+---------------+

Bref, les index HASH ne permettent pas de répondre à tous les types de requête.

Démonstration en utilisant la base bien connue « world » disponible au téléchargement sur le site de MySQL.
Issue de cette base, la table « country » contient 239 pays dont la clé primaire est un code de trois caractères, ‘FRA’ pour la France par exemple. On cherche à déterminer quels sont les pays dont le code abrégé est supérieur à la chaîne de caractère ‘TOTO’ .

Par défaut cette table est en MyISAM. Nous sommes donc en présence d’une implémentation B-TREE pour l’index. On effectue un EXPLAIN sur une requête très simple :

mysql> explain select * from country where code > ‘TOTO’\G
*************************** 1. row ******

id: 1
select_type: SIMPLE
table: country
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: NULL
rows: 27
Extra: Using where
1 row in set (0.00 sec)

(A noter : le « \G » permet un affichage vertical à partir du client mysql.)

On voit ici que la clé primaire est bien utilisée pour répondre à cette requête (key : PRIMARY).

Modifions le moteur de stockage pour du MEMORY et réappliquons la même requête :

mysql> alter table country engine = MEMORY;
Query OK, 239 rows affected (0.06 sec)
Records: 239 Duplicates: 0 Warnings: 0

mysql> explain select * from country where code > ‘TOTO’\G
*************************** 1. row ************

id: 1
select_type: SIMPLE
table: country
type: ALL
possible_keys: PRIMARY
key: NULL
key_len: NULL
ref: NULL
rows: 239
Extra: Using where
1 row in set (0.00 sec)

On voit ici que la recherche n’a pas pu s’effectuer via la clé primaire implémentée en HASH. La clé primaire est bien détectée comme candidate potentielle (possible_keys : PRIMARY) mais elle n’est finalement pas retenue (key : NULL) et c’est finalement un parcours total de la table qui sera effectué (type : ALL).

Les données n’étant pas ordonnées, l’indexation du champ « Code » n’a malgré tout pas permis de déterminer qu’elles étaient les valeurs des codes suivants ou précédents.

Bien évidemment sur un tel exemple à la volumétrie aussi faible, l’impact sur les performances est insignifiant. Néanmoins ceci permet de comprendre que la transformation d’une table MyISAM à une table MEMORY par un simple ALTER TABLE ne permet pas forcément d’obtenir le même plan d’exécution sur les deux moteurs et ceci pour une définition de table identique.
Il faut donc surveiller le plan d’exécution avant et après la transformation, ainsi que mesurer les performances obtenues (benchmarks) afin de mesurer l’impact du passage d’un moteur à l’autre. Accéder à des données en mémoire est bien sûr plus rapide qu’aller les chercher sur disque mais peut-être avez-vous réellement besoin qu’un index particulier soit pris en compte, à vous de le vérifier.

A noter enfin qu’il est possible avec le moteur MEMORY de définir pour une colonne donnée un HASH index non unique, c’est une implémentation des HASH index un peu particulière choisie par MySQL. La documentation conseille d’ailleurs à ce sujet d’utiliser l’implémentation B-TREE pour les champs dont les données sont trop redondantes. En effet, des ralentissements proportionnels à cette redondance sont à prévoir lors des UPDATE et DELETE. Un billet de Peter Zaitsev relate parfaitement ce phénomène.

InnoDB et l’ADAPTIVE HASH INDEX

Particularité d’InnoDB, ce moteur est capable de « transformer » les index B-TREE en équivalent HASH si l’optimiseur détecte qu’un gain est possible, d’où le nom de cette technique : ADAPTIVE HASH INDEX, (attention la traduction française utilise « base en mémoire », il s’agit d’une « table »).
Dans un tel cas, les index restent implémentés en B-TREE, cependant InnoDB peut créer à la volée des versions HASH de ces derniers. La commande SHOW INNODB STATUS est alors toute indiquée pour observer les performances relatives aux deux implémentations.

A retenir :

- Parmi MyISAM, InnoDB et MEMORY, seul le moteur de stockage MEMORY vous permet de choisir l’implémentation (B-TREE ou HASH) de vos index.
- Ce choix a une incidence sur le plan d’exécution de vos requêtes.
- Les index de type HASH sont très performants mais restreints aux opérateurs « = » et « <=> ».
- Les index de type B-TREE sont les plus utilisés et plus polyvalents (« = », « > », « >= », « < », « <= »).