Commençons par l’installation du script. Rien de plus simple, il vous suffit pour commencer de télécharger et de décompresser une archive de l’outil, disponible ici. Ensuite, des classiques

$ perl Makefile.PL
$ make
# make install

vous permettent d’installer le script. Notez, point agréable, qu’une page de man est intégrée. Si vous cherchez la syntaxe d’une option, un man mysqlsla vous dispensera donc bien souvent d’aller faire un tour sur le site du projet.

mysqlsla est plus généraliste que mysqldumpslow dans le sens où il est capable de traiter tout type de journal (requêtes lentes, mais aussi journal binaire ou journal général, ou encore journal défini par l’utilisateur). Les principes que nous allons voir dans cet article pour les requêtes lentes sont aussi valables pour les autres types de journaux.

L’idée de base de mysqlsla est de pouvoir analyser des fichiers journaux en leur appliquant éventuellement des filtres afin de ne garder que certains événements et d’émettre un rapport personnalisable présentant les résultats de cette analyse. Dans cet article nous allons seulement regarder les capacités de filtrage de mysqlsla et pas la manière de produire un rapport personnalisé, puisque le rapport par défaut nous convient très bien.

Pour un premier essai, lançons mysqlsla sans paramètre particulier à part l’option lt (comme log type) qui indique au script que le fichier passé est un journal de requêtes lentes. Cette option n’est en réalité pas indispensable car mysqlsla sait détecter automatiquement le type de journal :

$ mysqlsla -lt slow msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

________________________________________________ 001 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

________________________________________________ 002 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

A première vue, ce rapport ressemble à celui de mysqldumpslow avec un regroupement des requêtes similaires. Le rapport est cependant plus complet car pour chaque groupe, nous avons les valeurs minimales, moyennes et maximales ainsi qu’une information très intéressante sur le poids relatif de chaque groupe, ce qui permet de cibler facilement les requêtes qui ont le plus contribué au temps de réponse ou qui ont examiné le plus de lignes.

Autre point à noter : pour chaque groupe de requêtes, mysqlsla nous présente une vue abstraite de la requête, c’est-à-dire une requête générique où les paramètres qui varient entre les requêtes du groupe sont remplacés par N pour un nombre ou S pour une chaîne de caractères, mais aussi un exemple de requête avec des vrais paramètres. C’est un bon point par rapport à mysqldumpslow puisqu’il est facile avec l’exemple de regarder le plan d’exécution donné par la commande EXPLAIN.

Intéressons-nous aux 4 questions que nous nous étions posées lors de l’article précédent, qui vont nous permettre de voir comment utiliser les méta-données des requêtes pour trier ou filtrer.

Chaque requête dans le journal possède un certain nombre de méta-données, comme le temps d’exécution ou le nombre de lignes examinées. Il existe également des méta-données dérivées, comme la moyenne des temps d’exécution pour un groupe de requêtes. Les méta-données disponibles dépendent du type de journal considéré, et tout est détaillé dans la page de la documentation consacrée aux filtres.

mysqlsla nous permet de trier les résultats du rapport selon n’importe quelle méta-donnée avec l’option --sort.

Ceci va nous permettre de répondre aux 2 premières questions :

Quel est le groupe de requêtes ayant le plus long temps de réponse ?

$ mysqlsla -lt slow --sort t_sum msandbox-slow.log

Ici l’affichage est exactement celui que nous avions sans l’option --sort. C’est normal car pour les journaux de requêtes lentes, mysqlsla applique par défaut l’option --sort t_sum !

Quel est le groupe de requêtes ayant le plus grand nombre d’occurrences ?

$ mysqlsla -lt slow --sort c_sum msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 'c_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

_______________________________________________ 001 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

________________________________________________ 002 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

L’utilisation des filtres va nous permettre de répondre aux 2 dernières questions. Il faut savoir que mysqlsla dispose de deux types de filtres : le premier type permet de filtrer sur les méta-données des entrées du journal alors que le second permettre de sélectionner ou d’exclure un ou plusieurs types de requêtes. Ces deux types de filtres peuvent bien sûr être combinés afin de répondre à des questions complexes.

Les filtres sur les méta-données s’écrivent avec l’option --meta-filter (ou -mf en abrégé), comme par exemple -mf "db=sakila" pour ne conserver que les requêtes sur la base sakila ou -mf "db=sakila,c_sum>5" pour ne conserver que les requêtes sur la base sakila qui apparaissent au moins 6 fois.

Il est facile avec cette option de répondre à la 3è question :
Quelles sont les requêtes qui prennent plus de x secondes ?
En positionnant x à 0.1s, on obtient le résultat suivant :

$ mysqlsla -lt slow -mf "t>0.1" msandbox-slow.log
Report for slow logs: msandbox-slow.log
1 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 0, Rows Examined 16.04k

________________________________________________ 001 ___
Count : 1 (100.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (100.00%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (100.00%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (1) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;


Enfin nous allons nous servir des filtres sur les requêtes (option --statement-filter ou -sf) pour répondre à la 4è question :
Comment ne conserver que les requêtes SELECT ?

$ mysqlsla -lt slow -sf "+SELECT" msandbox-slow.log
Report for slow logs: msandbox-slow.log
3 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 0 s, Lock 0 s, Rows sent 1.80k, Rows Examined 48.13k

________________________________________________ 001 ___
Count : 3 (100.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (100.00%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (100.00%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (3) of all users

Query abstract:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

Et voilà, notre (courte) exploration de mysqlsla est terminée ! Ces quelques exemples ont montré que mysqlsla est extrêmement flexible comparé à mysqldumpslow, ce qui en fait un très bon choix en tant outil d’analyse de journaux MySQL. Quels sont les inconvénients de mysqlsla ? En fait, je n’en vois qu’un seul : Daniel, le développeur de mysqlsla, a annoncé au printemps que l’outil ne serait plus maintenu. La raison est simple : Daniel fait maitenant partie de l’équipe de développement de Maatkit, qui propose un outil remplaçant mysqlsla. Mais assez dit, ce sera l’objet du prochain article de cette série.

La désactivation du contrôle des clés étrangères est intéressante lorsque vous devez exécuter sur votre serveur MySQL un script de création de tables par exemple. Il se peut dans ce cas que l’ordre de création des différentes tables ne soit pas « logique ».

J’entends par là qu’une table A peut contenir une contrainte basée sur une clé étrangère référençant le champ d’une table B… qui n’existe pas encore ! La « logique » voudrait que les tables soient inscrites dans le script selon les liens qui existent entre elles mais cela n’est pas toujours le cas.

Cette opération de classement pouvant s’avérer fastidieuse à effectuer manuellement, vous pouvez vous affranchir des vérifications effectuées par le SGBD concernant les clés étrangères en utilisant la commande suivante :

mysql> SET foreign_key_checks = 0;

Vous êtes ainsi tranquille le temps de créer vos tables. Réactiver ce contrôle n’est pas plus compliqué :

mysql> SET foreign_key_checks = 1;

Le chapitre de la documentation correspondant aux foreign keys nous indique que c’est d’ailleurs la technique employée par mysqldump.

Pour exporter vos procédures stockées grâce à mysqldump, n’oubliez pas l’option -R. Sans elle votre prochaine restauration risque de vous apporter quelques surprises. Si les triggers sont bien sauvegardés par défaut, il n’en va pas de même pour les procédures stockées.

Ainsi :
mysqldump -umy_user -p MY_DB MY_TABLE1 MY_TABLE2 > /tmp/dump_my_db.sql

… Sauvegardera bien les tables MY_TABLE1 et MY_TABLE2 de la base MY_DB, mais pas les procédures stockées…

L’option -R permet de sauvegarder cette fois vos bases, procédures stockées comprises :

mysqldump -umy_user -p -R MY_DB MY_TABLE1 MY_TABLE2 > /tmp/dump_my_db.sql

Pour ne sauvegarder que vos procédures stockées, utilisez par exemple :

mysqldump –umy_user -p -R --all-databases --no-data --no-create-db --no-create-info > /tmp/dump_proc.sql

mysqldump est riche en options, un petit coup d’oeil sur la doc de temps en temps permet d’exploiter de nouvelles idées.

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.

Faute avouée est à demi-pardonnée, alors autant dire que publiée sur un blog elle est carrément excusée

« L’astuce » est donc la suivante :

Vérifiez que vos « clients » MySQL lisent bien le bon my.cnf… La doc ne fait pourtant pas mystère de la façon dont les fichiers de configuration (my.cnf en tête de gondole) sont lus.

« If multiple instances of a given option are found, the last instance takes precedence. » Autrement dit, le dernier qui parle à raison et mon my.cnf (/etc/my.cnf) était écrasé par d’autres copies de my.cnf dont je n’avais pas vérifié l’existence cette fois-ci.

Pour vérifier les fichiers lus par défaut (et dans quel ordre) :

> mysql --help | grep 'my.cnf'

On obtient sur cette machine :

order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

Si vous ne souhaitez pas que le /etc/mysql/my.cnf écrase ou redéfinisse certaines de vos variables (« datadir » et « basedir » par exemple) du /etc/my.cnf précédent, un renommage du my.cnf superflu résoudra le problème.

Le problème :
La partition accueillant le répertoire d’installation standard de notre MySQL arrivant à saturation, il devenait impossible de passer certaines commandes dont le ALTER TABLE. Celle-ci nécessite en effet la plupart du temps (pour MyISAM) la création de fichiers temporaires (.MYD, .MYI, .frm) dont les tailles sont semblables à celles des fichiers initiaux (aux modifications de structure près). Le hic : la taille restante sur cette partition ne permettait pas la création de tels fichiers.

Sur une table de plusieurs centaines de millions de lignes, pesant quelques dizaines de Go, un ALTER TABLE prend souvent plusieurs heures… Je vous conseille donc de vérifier dès le départ si vous disposez sur votre partition d’un espace au moins équivalent à la somme des .MYD + .MYI de votre table si vous souhaitez éviter de saturer totalement l’espace disque.

Si malgré tout vous poussez le vice jusqu’à défier toutes vos sondes de monitoring et obtenez un « Use 100% »  sur un « df -h », sachez que le .TMD susceptible de faire son apparition est là pour tenter de réparer les fichiers temporaires (au moins le .MYD) crées lors du ALTER TABLE. Cette étape supplémentaire rallonge fortement l’opération initiale à tel point qu’il est parfois plus judicieux de l’interrompre, supprimer les fichiers temporaires initialement crées par le ALTER, ainsi que le .TMD, et de tout reprendre à zéro avec cette fois un espace disque suffisant.

Pour éviter d’en arriver là, et si l’espace disque vient à manquer sur la partition de votre MySQL, les liens symboliques peuvent vous sauver la mise. Ils permettent de déplacer bases et tables MyISAM sur différentes partitions / disques, soit pour des raisons de performance (on peut alors allouer une base/table à un disque) soit comme ici surtout pour des raisons de place.

Le jonglage à base de liens symboliques permet-il d’éviter tous les problèmes ? Quel rôle joue la variable TMPDIR ?

Autant être clair dès maintenant, la variable TMPDIR n’intervient pas dans le cadre d’un ALTER TABLE. Si celle-ci désigne bien l’emplacement où MySQL stocke ses fichiers temporaires, un ALTER TABLE crée une table temporaire dans le même répertoire que la table originale.

En effet :

mysql> show variables like ‘tmpdir’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| tmpdir        | /tmp  |
+—————+——-+
1 row in set (0.00 sec)

debian:~/sandboxes/msb_5_1_28/data/test# ls -l

-rw-rw—- 1 root root     8644 2009-02-08 02:52 t.frm
-rw-rw—- 1 root root 20000000 2009-02-08 02:52 t.MYD
-rw-rw—- 1 root root 17444864 2009-02-08 02:52 t.MYI

Pendant l’exécution du ALTER TABLE on obtient :

debian:~/sandboxes/msb_5_1_28/data/test# ls -l

-rw-rw—- 1 root root     8616 2009-02-08 08:00 #sql-e1c_1.frm
-rw-rw—- 1 root root  1966080 2009-02-08 08:00 #sql-e1c_1.MYD
-rw-rw—- 1 root root     1024 2009-02-08 08:00 #sql-e1c_1.MYI
-rw-rw—- 1 root root     8644 2009-02-08 02:52 t.frm
-rw-rw—- 1 root root 20000000 2009-02-08 02:52 t.MYD
-rw-rw—- 1 root root 17444864 2009-02-08 02:52 t.MYI

Après l’opération :

debian:~/sandboxes/msb_5_1_28/data/test# ls -l

-rw-rw—- 1 root root     8616 2009-02-08 08:00 t.frm
-rw-rw—- 1 root root  9000000 2009-02-08 08:00 t.MYD
-rw-rw—- 1 root root 17422336 2009-02-08 08:01 t.MYI

Les fichiers temporaires liés à la reconstruction de la nouvelle table (#…) sont bien situés dans le répertoire de la table d’origine, et non pas dans /tmp.
Dans le cadre d’un GROUP BY ou ORDER BY, MySQL peut avoir besoin de créer des fichiers temporaires dont l’emplacement sera cette fois défini par la variable TMPDIR.

La création des fichiers temporaires au sein même du répertoire d’origine de la table n’est pas vraiment souhaitable si l’on manque d’espace disque, comment régler le problème ?

Tentons de déplacer la table incriminée par des liens symboliques.

Deux remarques importantes :

1. – le .frm doit rester dans le répertoire initial, il ne peut pas être transformé en lien symbolique, en revanche le .MYD et le .MYI peuvent être déplacés où bon vous semble, il est notamment possible de les stocker chacun dans un répertoire différent.
2. - La documentation stipule que la manipulation d’une table MyISAM par liens symboliques doit s’effectuer serveur MySQL éteint. La « procédure » fonctionne serveur allumé mais vous vous exposez à différents problèmes : accès aux tables concernées pendant la procédure de déplacement de vos tables et résultats aléatoires.

J’ai effectué de nombreux tests avec un serveur MySQL non coupé, les résultats varient selon les exécutions, les versions de MySQL… Difficile d’établir une conclusion concernant un comportement de MySQL lorsque le serveur fonctionne et qu’on utilise les liens symboliques pour déplacer une table, voici différents comportements que j’ai observé :

• Tout se passe bien : vos tables pointent vers un autre répertoire, vous appliquez le ALTER TABLE et les fichiers temporaires suivent les liens symboliques pour être finalement crées sur le répertoire de destination, tout est ok.
• MySQL est susceptible de supprimer vos liens symboliques en fin d’ALTER TABLE, alors que vos .MYD et .MYI du répertoire cible sont supprimés pour être finalement recrées dans le répertoire initial.
• MySQL semble avoir du mal avec les liens symboliques détenus par root… J’ai remarqué qu’avec un chown -h mysql:root par exemple, le serveur MySQL s’en sortait mieux. A noter que la 5.1.30 semble faire effectuer ce « changement de propriétaire » d’elle même : en fin d’ALTER TABLE mes liens symboliques sont passés de root:root à mysql:mysql.

Bref, d’une façon générale avant de vous lancer dans le symlinking d’une très lourde table, testez d’abord la manipulation sur une table plus modeste afin de vérifier comment se comporte votre serveur MySQL, ceci tout particulièrement si vous comptez effectuer l’opération serveur allumé (encore une fois non recommandé, attention aux accès potentiels sur vos tables…).

La procédure à suivre pour vos tests est simple, voici la mienne :

J’ai repris la structure de la table d’un billet précédent (générer un jeu de données), ainsi que la procédure stockée nécessaire pour la renseigner, souvent 1M de lignes pour mes tests (à varier selon votre configuration, il faut que les ALTER TABLE que vous passerez soient suffisamment longs pour vous laisser le temps d’effectuer au moins un « ls -l »

J’ai initialement mes 3 fichiers de ma table MyISAM « t » :

debian:~/sandboxes/msb_5_1_28/data/test# ls -l
-rw-rw—- 1 root root 8616 2009-02-08 13:34 t.frm
-rw-rw—- 1 root root 4500000 2009-02-08 13:34 t.MYD
-rw-rw—- 1 root root 8177664 2009-02-08 13:34 t.MYI

On déplace les fichiers .MYD et .MYI vers un répertoire cible :
mv t.M* /symlink_test

On ajoute les liens symboliques :

ln -s /symlink_test/t.MYD t.MYD
ln -s /symlink_test/t.MYI t.MYI

debian:~/sandboxes/msb_5_1_28/data/test# ls -l
-rw-rw—- 1 root root … 13:34 t.frm
lrwxrwxrwx 1 root root  … 13:49 t.MYD -> /symlink_test/t.MYD
lrwxrwxrwx 1 root root  … 13:49 t.MYI -> /symlink_test/t.MYI

Les fichiers .MYD et .MYI sont situés dans /symlink_test et on applique un ALTER TABLE à notre table.
Voici quelques résultats obtenus pendant le ALTER TABLE…

Cas 1 : MySQL ne suit pas les liens symboliques :

/var/database/mysql50/tmp# ls -l

-rw-rw—- 1 mysql mysql   … 23:34 #sql-fe6_6e715a.frm
-rw-rw—- 1 mysql mysql … 23:34 #sql-fe6_6e715a.MYD
-rw-rw—- 1 mysql mysql   … 23:34 #sql-fe6_6e715a.MYI
-rw-rw—- 1 mysql mysql   … 23:31 t.frm
lrwxrwxrwx 1 root  root      … 23:33 t.MYD -> /sym/t.MYD
lrwxrwxrwx 1 root  root      … 23:33 t.MYI -> /sym/t.MYI
… et finalement les supprime en fin d’ALTER TABLE :

/var/database/mysql50/tmp# ls -l

-rw-rw—- 1 mysql mysql  … 23:34 t.frm
-rw-rw—- 1 mysql mysql … 23:34 t.MYD
-rw-rw—- 1 mysql mysql … 23:34 t.MYI

A tout hasard vérifiez la variable ‘have_symlink’ dans votre configuration, elle est normalement activée par défaut :
mysql> show variables like ‘have_symlink’;

+—————+——-+
| Variable_name | Value |
+—————+——-+
| have_symlink  | YES   |

Cas 2 : MySQL suit les liens symboliques :

-rw-rw—- 1 root root 8644 2009-02-08 14:01 #sql-e1c_1.frm
lrwxrwxrwx 1 root root  … #sql-e1c_1.MYD -> /symlink_test/test/#sql-e1c_1.MYD
lrwxrwxrwx 1 root root  … #sql-e1c_1.MYI -> /symlink_test/test/#sql-e1c_1.MYI
-rw-rw—- 1 root root … t.frm
lrwxrwxrwx 1 root root   … t.MYD -> /symlink_test/test/t.MYD
lrwxrwxrwx 1 root root   … t.MYI -> /symlink_test/test/t.MYI

… sur le répertoire cible on constate la présence des fichiers temporaires :
debian:/symlink_test/test# ls -l
-rw-rw—- 1 root root 20000000 2009-02-08 14:01 #sql-e1c_1.MYD
-rw-rw—- 1 root root  9265152 2009-02-08 14:01 #sql-e1c_1.MYI
-rw-rw—- 1 root root 10000000 2009-02-08 13:58 t.MYD
-rw-rw—- 1 root root 18443264 2009-02-08 13:59 t.MYI

Si vous en avez la possibilité, suivez les préconisations de la doc MySQL et établissez un lien symbolique sur la base entière plutôt que sur une table en particulier.
Ex :

debian:~/sandboxes/msb_5_1_28/data/test# cd ..
debian:~/sandboxes/msb_5_1_28/data# mv test /symlink_test/
debian:~/sandboxes/msb_5_1_28/data# ln -s /symlink_test/test test
debian:~/sandboxes/msb_5_1_28/data# ls -l
lrwxrwxrwx 1 root root … 16:08 test -> /symlink_test/test

Et dans le répertoire cible, pendant l’exécution du ALTER TABLE :

debian:/symlink_test/test# ls -l
-rw-rw—- 1 root root     … 16:08 #sql-1efe_1.frm
-rw-rw—- 1 root root  … 16:08 #sql-1efe_1.MYD
-rw-rw—- 1 root root  … 16:08 #sql-1efe_1.MYI
-rw-rw—- 1 root root     … 15:58 t.frm
-rw-rw—- 1 root root … 15:58 t.MYD
-rw-rw—- 1 root root … 15:58 t.MYI

… les fichiers temporaires ont bien suivi le lien symbolique, c’est la méthode recommandée par MySQL : le déplacement d’une base entière.

A noter qu’il est également possible d’établir de faire pointer un .MYD et un .MYI vers un répertoire précis via respectivement DATA DIRECTORY et INDEX DIRECTORY, deux options disponibles pour un CREATE TABLE. Malheureusement un ALTER TABLE ne peut pas modifier ces valeurs.

Les liens relatifs à notre thème du jour sur la doc MySQL :
http://dev.mysql.com/doc/refman/5.1/en/temporary-files.html
http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_tmpdir
http://dev.mysql.com/doc/refman/5.1/en/symbolic-links-to-tables.html

Sans rentrer dans les détails, nous avons une simple table qui stocke différents métrics mesurés sur plusieurs serveurs. Nous avons à faire une application de monitoring.

mysql> desc default_summary;
+—————+——————+——+—–+———+—————-+
| Field | Type | Null | Key | Default | Extra |
+—————+——————+——+—–+———+—————-+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| host | char(25) | NO | MUL | | |
| date | datetime | NO | MUL | | |
| metric1 | float | YES | | NULL | |
| metric2 | float | YES | | NULL | |

mysql> select host,date, metric1 from default_summary limit 5;
| host1 | 2009-11-06 17:00:00 | 5 |
| host2 | 2009-11-06 17:00:00 | 6 |
| host3 | 2009-11-06 17:00:00 | 7 |

Ce que mon ami aimerait avoir est:
| 2009-11-06 17:00:00 | 5 | 6 | 7 |

Donc comment arriver à ce résultat sans passer pas des tables temporaires, qui est aussi une solution dans certains cas?

select date
sum( case host when ‘host1′ then metric1 else 0 end ) as host1,
sum( case host when ‘host2′ then metric1 else 0 end ) as host2,
sum( case host when ‘host3′ then metric1 else 0 end ) as host3,
….
from default_summary
group by date;

Il faut évidemment connaitre tous les valeurs de host dés le début… humm je sens que je vais bientôt coder une petite fonction

Il y a plusieurs solutions possibles sous d’autre SGBD comme Oracle ( PL/SQL, SYS_CONNECT_BY_PATH, Oracle Cross Join ) mais ceci est une autre histoire!

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

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.