Nous repartons de la table du post précédent, remplie avec 500 000 enregistrements :
CREATE TABLE product (
product_id int(11) NOT NULL AUTO_INCREMENT,
category_id int(11) NOT NULL DEFAULT 0,
reference varchar(20) NOT NULL DEFAULT '',
name varchar(25) NOT NULL DEFAULT '',
sold int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (product_id)
) ENGINE=MyISAM;

Nous voulons, à partir de cette table de produits, trouver pour chaque catégorie le produit qui s’est le plus vendu.

Première idée : raisonner en terme de boucle, c’est-à-dire demander au SGBD de retrouver pour chaque catégorie le produit qui s’est le plus vendu. Cela donne en SQL la requête suivante :

mysql> SELECT sql_no_cache pdt.*
FROM product pdt
WHERE sold =
(SELECT MAX(sold) FROM product
WHERE category_id = pdt.category_id);


On note la sous-requête corrélée, qui traduit en SQL notre idée de boucle à travers l’ensemble des catégories.

Temps d’exécution : très long… en effet j’ai arrêté l’exécution de la requête au bout de 20 mn, et toujours pas de résultat en vue à ce moment-là ! Un bon index est sans doute nécessaire…

Examinons le résultat de la commande EXPLAIN :

mysql> EXPLAIN SELECT...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
2 rows in set (0,00 sec)


Effectivement, ce n’est pas fameux : pour chaque ligne de la table product, MySQL va exécuter la sous-requête, qui elle-même fait un scan complet de la table product… On est dans une situation bien pire qu’un CROSS JOIN, ce qui explique la lenteur constatée.

Un index composite sur (category_id, sold) va bien nous permettre d’améliorer la sous-requête…

mysql> ALTER TABLE product add index idx_category_sold (category_id,sold);
mysql> EXPLAIN SELECT ...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 4
ref: test.pdt.category_id
rows: 500
Extra: Using index
2 rows in set (0,00 sec)


… mais il n’existe pas de moyen d’améliorer la requête principale.

Le temps d’exécution après ajout de l’index est maintenant de 2mn15, ce qui est encore loin d’être satisfaisant.

La limitation de notre requête, comme nous l’a montré la commande EXPLAIN, c’est que pour chacune des 500 000 lignes de la table, MySQL va devoir exécuter la sous-requête. Cela signifie que même en optimisant au mieux la sous-requête, celle-ci sera toujours exécutée 500 000 fois, ce qui est forcément couteux. Ajouter un index ne fait que limiter les dégâts, mais ne suffit pas pour obtenir des performances correctes.

La vraie solution à notre problème va consister à changer de point de vue sur la demande initiale formulée en langage courant, afin de pouvoir écrire la requête d’une toute autre manière, qui, espérons-le, sera plus efficace.

Nous allons donc raisonner de façon ensembliste. Avec notre table, il nous est possible de constituer deux ensembles : l’ensemble E1 des informations sur les produits (facile : SELECT * FROM product) et l’ensemble E2 des produits qui se sont le mieux vendus (facile aussi : SELECT category_id, MAX(sold) FROM product GROUP BY category_id). Si nous sommes capables de faire l’intersection entre E1 et E2, nous aurons résolu notre problème.

Or faire l’intersection de deux ensembles se traduit en SQL par une jointure entre deux tables. La solution est donc toute tracée :

mysql> SELECT sql_no_cache pdt.* FROM (
SELECT category_id, MAX(sold) as maxi
FROM product
GROUP BY category_id
) AS maxi_list
INNER JOIN product pdt
ON pdt.category_id = maxi_list.category_id
AND pdt.sold = maxi_list.maxi;


EXPLAIN nous montre comment est exécutée cette nouvelle requête :

mysql> EXPLAIN SELECT ... \G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table:
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra:
***************** 2. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 8
ref: maxi_list.category_id,maxi_list.maxi
rows: 1
Extra:
***************** 3. row *****************
id: 2
select_type: DERIVED
table: product
type: range
possible_keys: NULL
key: idx_category_sold
key_len: 4
ref: NULL
rows: 1001
Extra: Using index for group-by
3 rows in set (0,05 sec)


MySQL exécute d’abord la sous-requête puis place le résultat dans une table temporaire, qui est jointe à la table product. A noter que la jointure se fait avec deux conditions, qui sont nécessaires toutes les deux.

Quel est le temps d’exécution de cette requete ? 0.06s… Pas besoin de commentaire, le gain est vertigineux !

Ces deux articles nous ont donc permis de voir que la manière dont une requête est formulée peut avoir des conséquences très importantes sur les temps d’exécution. Il n’existe pas de règle pour savoir si une requête est bien écrite ou pas, mais quand vous rencontrez une requête utilisant de bons index mais qui est lente, il peut être très intéressant de réfléchir à son sens pour trouver une réécriture qui sera performante.

Il en ressort que pas mal d’affirmations et de recommendations sont hardcodées et ne tiennent absolument pas compte des spécificités de votre base. Un exemple ? Si le cache de requêtes est désactivé, alors le script va systématiquement vous remonter qu’il s’agit d’un problème, même si vous avez sciemment désactivé ce cache.

A partir de toutes ces constatations, Sheeri a commencé à faire évoluer le script, en ajoutant pour l’instant quelques options intéressantes, comme celle permettant de formater le rapport de manière à le rendre facilement lisible par un tableur : il devient ainsi plus facile de voir l’évolution de certains indicateurs dans le temps en lançant le script à intervalles réguliers. A suivre !

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…

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.

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 (« = », « > », « >= », « < », « <= »).

Un slave n’enregistre pas dans son journal (ses binlogs) les commandes qu’il reçoit de son master. Donc dans notre cas (B) est à jour mais (C) n’a aucun moyen de connaître les commandes car (C) lit juste les binlogs de (B).

En rajoutant log-slave-updates dans le my.cnf de (B), il écrira toutes les commandes dans les binlogs et (C) sera ainsi à jour.

C’est aussi un bon moyen pour contrôler toutes les commandes exécutées sur votre slave. Cela m’a permis un jour de trouver la source d’un problème. Un client mal configuré venait mettre à jour un slave et faisait ainsi planter la réplication.

La question est pourquoi? Performances!

Pour gagner en performances, vous voulez que votre base pré alloue de l’espace disque, des blocks de data pour vous. Nous parlons alors d’extend. Vu ces conditions veut on vraiment désallouer des extends pour les réallouer ensuite? La réponse est non!

Comment alors récupérer de l’espace? La seule solution est d’exporter les data, d’effacer les files et importer le tout.

Que peut on faire pour optimiser ça?

Effacer un maximum avant d’ajouter de l’information et ainsi contrôler du mieux que l’on peut la taille de votre tablespace.

Et pour MySQL?

Après avoir discuté avec Peter Zaitsev et Heikki Tuuri, il semblerait que « innodb_file_per_table » qui est apparu avec MySQL 4.1.3, pourrait contourner le problème. Cela semblerai être plus performant qu’un seul tablespace.

« innodb_file_per_table » est un paramètre de configuration dans le my.cnf, et est pris en compte seulement lors de la création d’une table. Donc pour migrer d’un seul tablespace vers plusieurs fichiers vous devrez encore une fois faire un export/import.

Une fois ceci fait, si vous effacez vos entrées et faite un « OPTIMIZE TABLE » l’OS libérera l’espace. Chaque table a son propre fichier .ibd et la commande recrée un fichier, efface l’ancien et renomme le nouveau.

Ce qui veut dire qu’a un instant t vous avez 2 fois les data, prévoyez donc une place suffisante sur votre disque et n’attendez pas le dernier moment.

Pour conclure, autoextend c’est bien mais vous devez néanmoins surveillez ça de prés.

mysql> show status like ‘Com_select’;
+—————+————+
| Variable_name | Value |
+—————+————+
| Com_select | 2293615720 |
+—————+————+
1 row in set (0.00 sec)

Voila le nombre de select qu’il y a eu sur ce server, 2.3 milliards… oups…

mysql> show status like ‘Questions’;
+—————+———–+
| Variable_name | Value |
+—————+———–+
| Questions | 533719732 |
+—————+———–+
1 row in set (0.00 sec)

‘Questions’ est le nombre de requêtes et commandes envoyées au serveur et devrait donc être logiquement la somme de toutes les « Com_* ».
Est ce un bug? 533 millions alors que rien qu’en select je suis déjà à 2.3 milliard?

En fait tous ces compteurs sont des entiers non signés. Donc sur des plateformes 32bit nous atteignons un maximum de 4.2 milliards avant que cela revienne à zéro. Donc tout est bien normal ici.

Maintenant la valeur qui est bizarre pour moi est ‘Com_admin_commands’.

mysql> show status like ‘Com_admin_commands’;
+——————–+————+
| Variable_name | Value |
+——————–+————+
| Com_admin_commands | 2731594764 |
+——————–+————+
1 row in set (0.00 sec)

2,7 milliards, ok mais à quoi correspond une commande admin? Je n’ai pas trouvé une seule ligne de documentation la dessus. Donc la seule solution est de regarder le code source (J’adore l’Open Source). C’est ainsi que l’on découvre que cela correspond à

• COM_TABLE_DUMP: demande au serveur d’envoyer la définition des tables et les data au format RAW. C’est utilisé par la réplication si vous utilisez LOAD DATA FROM MASTER. C’est commande est obsolète, NE PLUS UTILISER.
• COM_CHANGE_USER: dit au serveur que le client veut changer le user associé à la session – mysql_change_user( ).
• COM_BINLOG_DUMP: demande au serveur d’envoyer un flux constent des binlogs à partir d’une certaine valeur – mysqlbinlog
• COM_SHUTDOWN: commande l’arrêt du serveur – mysql_shutdown( )
• COM_PING: ping pour MySQL – mysql_ping( )
• COM_DEBUG: force un dump dans le log d’erreurs – mysql_dump_debug_info( )

Pour plus de détails la dessus, je vous conseille le nouveau livre de Sasha Pachev aux éditions O’Reilly, Understanding MySQL Internals qui est sorti en Avril 2007 et a été présenté pendant la conférence MySQL.

Donc revenons à cette base, nous avons 2.3 milliards de commandes admin, et cela semble être le plus vraisemblablement à cause de la fonction ping. Je me demande vraiment à quoi cela peut servir si ce n’est à garder des connections ouvertes pour rien.

• à t, je ping tout est ok
• à t+1, je perd ma connection
• à t+2, j’execute ma commande et j’ai pas de connection

C’est une fonction faite pour les clients qui gardent les connections en attente pendant longtemps…ce qui est INUTILE avec MySQL. Au lieu de garder des connections dans le vide… FERMEZ les!

La valeur par défaut du paramètre est de 100.


mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 100 |
+-----------------+-------+


Donc à vous de connaître vos besoins et d’allouer un nombre maximum suffisant pour votre application. Cela peut être utile pour vous montrer une erreur logicielle si le nombre est trop important.

Maintenant quelle est le problème si j’autorise trop de connexions simultanées. Tout simplement d’ utiliser trop de mémoire et de planter votre serveur. Il faut garder en tête cette rapide équation:

Un connexion ( MySQL thread ) utilise en RAM au maximum:
( thread_stack + net_buffer_length + max_allowed_packet + read_buffer_size + join_buffer_size + tmp_table_size + myisam_sort_buffer_size )

Sachant que vous avez déjà alloué de la mémoire à votre buffer pool / key cache, restez vigilant à ne pas dépasser le total de votre serveur.

Avec MySQL 5.0, une nouvelle variable est apparue, ‘max_user_connections’ pour limiter le nombre de connexions concurrentes pour un même utilisateur. C’est une variable globale pour TOUS les utilisateurs et activée pour les valeurs > 0.


mysql> show variables like 'max_user_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| max_user_connections | 0 |
+----------------------+-------+