Le livre est bien sûr disponible dans toutes les bonnes librairies informatiques et autres FNAC, Amazon …

Bonne lecture !

Vous trouverez ici-même le sommaire et l’avant-propos. Le premier chapitre (« Gérer une situation d’urgence avec MySQL »), est disponible sur le blog d’Olivier.

Le livre sort ce jeudi en librairie, fnac.com, eyrolles.com, amazon.fr…

Bonne lecture !

MySQL 5 Audit et optimisation

La rédaction de l’ouvrage étant maintenant dernière nous, les billets vont pouvoir reprendre à une allure plus digne de ce blog ! Je tiens d’ailleurs à remercier Stéphane qui a enrichi le site pendant que Pascal et moi étions à 100% sur le livre : l’intérêt de blogger en équipe…

La date officielle de sortie est le 25 mars. D’ici là voici le pdf du communiqué de presse concernant l’ouvrage. Celui-ci était présent en quantité limitée lors du dernier salon Solutions Linux.

Il est d’ores et déjà disponible en précommande.

Nous posterons ici même d’ici peu quelques morceaux choisis en pdf issus du livre dès que nous les aurons reçus de notre éditeur, c’est imminent.

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.

Non, ça n’est pas la dernière énigme à la mode pour rentrer chez Google mais plutôt une question qui pourrait devenir presque banale pour un entretien d’embauche pour un DBA MySQL à l’avenir, qui sait ?

Face à un tel défi, trois solutions :

- La fuite (mais faites une croix sur la « recommandation » Linkedin)
- Le kernel panic
- MySQL Sandbox !

Bien vu, MySQL Sandbox est la réponse la plus stratégique pour la poursuite de votre carrière.

Giuseppe Maxia (dont le blog figure dans notre blogroll, allez y jeter un oeil) est l’auteur de cet outil vraiment très pratique.  Que propose t-il ?

L’idée est d’automatiser l’installation de plusieurs serveurs MySQL sur une même machine. Rien que nous ne puissions faire manuellement c’est vrai, cependant la procédure habituelle consistant à ne pas mélanger les répertoires d’installation, choisir un port différent par serveur, appliquer mysql_secure_installation… Tout cela gagnerait à être automatisé non ? De plus ces installations manuelles sont potentiellement sources d’erreurs.

MySQL Sandbox est compatible avec toutes les versions MySQL de la 3.23 à la 6.0. Les différentes installations effectuées sont indépendantes les unes des autres, on peut ainsi faire cohabiter sans risque de conflits plusieurs versions différentes de MySQL sur une même machine (ports, répertoires et sockets indépendants).

En plus d’automatiser ces processus d’installation (gain de temps), MySQL Sandbox ne s’arrête pas là et  propose également des commandes très simples pour gérer les serveurs une fois installés.

Concernant le gain de temps, son auteur promet (notamment en page 2 de cette présentation) l’installation d’une réplication MySQL en 15 secondes. Info ou intox ?

Installation et pré-requis

Pour fonctionner MySQL Sandbox n’a besoin que des binaries des versions que vous souhaitez installer.

L’installation est très rapide :

Après avoir téléchargé MySQL Sandbox, il suffit de le décompresser dans le répertoire de votre choix :

debian:/opt# tar xzvf mysql_sandbox_2.0.11.tar.gz

On remarque alors que différentes commandes sont à notre disposition, plutôt explicites :

-rwxr-xr-x 1 501 staff  6154 2008-10-05 07:42 make_multiple_custom_sandbox
-rwxr-xr-x 1 501 staff  9062 2008-10-05 07:42 make_multiple_sandbox
-rwxr-xr-x 1 501 staff 12180 2008-10-05 07:42 make_replication_sandbox
-rwxr-xr-x 1 501 staff  5786 2008-10-05 07:42 make_sandbox

make_sandbox : installe un serveur MySQL simple
make_replication_sandbox : installe une réplication (par défaut un master, 2 slaves)
make_multiple_sandbox : pour installer plusieurs serveurs identiques
make_multiple_custom_sandbox : permet d’installer plusieurs serveurs de versions différentes

Installer une réplication

Une fois le binary récupéré, nous utilisons la commande make_replication_sandbox pour obtenir un master et deux slaves. Elle prend en paramètre le tar.gz du binary (d’autres raccourcis sont possibles, je vous renvoie au fichier README de l’outil).

debian:/opt/mysql_sandbox_2.0.11# ./make_replication_sandbox /opt/mysql-5.0.67-linux-i686-glibc23.tar.gz

La sortie écran donne ceci :
installing and starting master
installing slave 1
installing slave 2
starting slave 1
. sandbox server started
starting slave 2
.. sandbox server started
initializing slave 1
initializing slave 2
replication directory installed on /root/sandboxes/rsandbox_5_0_67

C’est fait ! L’installation en elle-même a duré un peu plus de 15 secondes, disons que les lignes de commande à taper tiennent dans ce laps de temps…

Par défaut les « bacs à sable » installés par MySQL Sandbox se placent dans $HOME/sandboxes/. Dans le cadre de notre réplication, celle-ci a été installée ici : debian:~/sandboxes/rsandbox_5_0_67#

Notre réplication est d’ores et déjà fonctionnelle, on peut le vérifier en se connectant par exemple au slave numero 2 (faites un ps-ef | grep mysql pour afficher rapidement les noms/localisations des sockets par ex)

debian:/home/user# mysql –socket=/tmp/mysql_sandbox29473.sock -p

Le password par défaut est « msandbox ».

mysql> show slave status\G
Slave_IO_State: Waiting for master to send event
Master_Host: 127.0.0.1
Master_User: msandbox
Master_Port: 29472
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 628
Relay_Log_File: mysql_sandbox29473-relay-bin.000002
Relay_Log_Pos: 765
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

La réplication fonctionne, le pari est tenu !

Les autres commandes disponibles

Evoquées plus haut les commandes make_multiple_custom_sandbox, make_multiple_sandbox, make_sandbox et make_replication_sandbox vous permettent d’installer différentes topologies de serveurs MySQL, du master-master au groupe de serveurs aux versions identiques ou pas.

Exemple, pour installer la version MySQL 5.1.28 sur la même machine que notre réplication précédente :

debian:/opt/mysql_sandbox_2.0.11# ./make_sandbox /opt/mysql-5.1.28-rc-linux-i686-glibc23.tar.gz

Résultat :

« Your sandbox server was installed in /root/sandboxes/msb_5_1_28. », simple non ?

D’autres commandes existent pour gérer votre installation :

start, restart, stop, clear… un suffixe « _all » pour les réplications vient s’ajouter aux commandes précédentes, ex « stop_all« .

« m » est le raccourci de master, « s1″, « s2″, etc concernent les slaves.

Ainsi pour arrêter totalement notre configuration de réplication précédente, on effectue :

debian:~/sandboxes/rsandbox_5_0_67# ./stop_all

A l’écran :

executing « stop » on slave 1
executing « stop » on slave 2
executing « stop » on master

Comme vous le voyez, MySQL Sandbox est très simple d’emploi.

Pour aller plus loin je vous conseille vivement la lecture (c’est rapide) du wiki de l’outil. Il reprend en fait le fichier README. Clair et concis vous y trouverez certainement votre bonheur : grâce à MySQL Sandbox, tester une nouvelle version de MySQL devient un jeu d’enfant.

Le shell

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

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

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

Puis :

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

Notre million de lignes est inséré.

mysqlslap

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

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

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

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

La procédure stockée : REPEAT… UNTIL

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

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

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

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

Pour appeler celle-ci :

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

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

Mission accomplie ? Presque…

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

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

La commande ANALYZE permet de laver cet affront :

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

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

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

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

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

Indexer, pourquoi ?

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

Principe de fonctionnement

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

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

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

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

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

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

Notre terrain de jeu, la base « world »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pour visualiser les index d’une table :

mysql> SHOW INDEX FROM Country;

Attention aux doublons !

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

Quels types de champ indexer ?

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

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

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

Soyez radins !

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

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

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

Le tips dbnewz : utilisez la commande PROCEDURE ANALYSE()

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

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

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

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

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

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

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

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

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

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

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

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

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

… Indexez Name et tout ira bien.

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

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

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

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

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

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

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

mysql> SHOW INDEX FROM City;


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

|name_cc_dis_pop |   1 |  Name

|name_cc_dis_pop |   2 | CountryCode

|name_cc_dis_pop |   3 | District

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

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

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

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

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

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

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

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

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

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

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

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

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

Mesurez l’efficacité des index avec EXPLAIN

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

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

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


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

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

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

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

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

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

mysql> CREATE INDEX idx_pop ON City (Population);

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

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

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

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

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

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

Cet outil n’est pas nouveau, son successeur officiel est même déjà connu, il s’agit de MySQL Workbench. Celui-ci n’étant pas encore disponible sous linux, nous utiliserons son ancêtre et plus particulièrement sa fonctionnalité de « reverse engineering » : une fois connecté à votre base, DBDesigner 4 va générer sous forme graphique vos tables, leurs descriptions, et si tout se passe bien, les relations entre vos tables.

Installation (fastidieuse) sous linux

L’installation de DBDesigner 4 sous linux (ubuntu 8.04 pour ma part) n’est pas de tout repos… J’ai rencontré toutes les erreurs potentielles croisées sur les différents tutoriels sur le sujet. Résultat des courses : il apparaît plus simple d’installer DBDesigner 4 en passant par wine, les problèmes de librairies manquantes disparaissent et les polices sont plus travaillées.
Si néanmoins vous souhaitez vous passer de wine, voici quelques pistes : http://wiki.splitbrain.org/dbdesigner et un how-to tiré des forums ubuntu. Des solutions sont proposées pour ces fameuses libraries manquantes, cela dit j’avais toujours des problèmes malgré ces manipulations.

Une fois wine installé (apt-get install wine), téléchargez simplement le fichier d’installation de DBDesigner 4 pour windows.

L’installation s’effectue simplement :

root@u200:/opt# wine DBDesigner4.0.5.6_Setup.exe

Si vous êtes sous MySQL 5, vous devez modifier le mot de passe de l’utilisateur à partir duquel vous vous connectez à DBDesigner de la façon suivante :

mysql> SET PASSWORD FOR 'dbdesign'@'localhost' = OLD_PASSWORD('dbdesign');

Depuis sa version 5, MySQL utilise en effet un mécanisme d’authentification qui est incompatible avec les versions précédentes (< 4.1). Afin d’assurer une rétro compatibilité, il est néanmoins possible avec MySQL 5 d’utiliser la commande « OLD_PASSWORD« , le format utilisé pour le mot de passe sera alors compatible avec MySQL 4 (short hash contre long hash pour MySQL 5).

Lancement de l’application:

root@u200:~/.wine/drive_c/Program Files/fabFORCE# wine DBDesigner4.exe

Obtenir le schéma de sa base

Pour générer votre MCD, et selon votre langue d’installation :

- Choisissez le menu « Database », puis « Reverse Engineering ».

- Selectionnez une connexion à la base de données ou créez la vôtre : « Localhost 127.0.0.1″ par exemple, puis renseignez vos login/pwd et validez, n’oubliez pas la commande « OLD_PASSWORD » si besoin.

- La fenêtre « Reverse Engineering » affiche alors la liste des tables de la base, par défaut elles sont toutes cochées. Remarquez un peu plus bas l’option « Build Relations« , cochez-là puis indiquez « Build Relations based on primary keys ». C’est grâce à cette option que vous indiquez à DBDesigner de relier vos tables entre elles (si possible).

- Si tout s’est bien passé, l’étape suivante affiche vos tables, leurs champs, leurs clés…

Remarques :

- DBDesigner ne parvient pas à joindre les tables de la base « world » entre elles, les noms des clés primaires sont différents et les clés étrangères absentes de la définition des tables (MyISAM), vous pouvez néanmoins rajouter vos différentes relations à la main.

- En ce qui concerne la base « sakila » les relations entre les tables sont bien présentes :

Vous pouvez à présent d’un seul coup d’oeil construire vos requêtes, les jointures entre les tables sont ici évidentes.

- La console dans laquelle vous lancez DBDesigner va peut-être contenir quelques messages d’erreur du type:

QPixmap::operator=: Cannot assign to pixmap during painting
QPopupMenu: (unnamed) Popup has invalid menu item

Cela n’a pas bloqué le comportement de l’application lors de mes tests cependant DBDesigner a la facheuse tendance à ouvrir des boites de dialogues sous les fenêtres déjà existantes, n’hésitez pas notamment lors de votre connexion à la base, à déplacer vos fenêtres (la principale et celle consacrée au reverse engineering) pour faire apparaître la boîte de dialogue vous invitant à renseigner vos identifiants de connexion. A noter qu’il existe là aussi des solutions pour régler ce problème de pop-up, cf les tutoriels cités en début d’article.

Pour explorer les autres fonctionnalités de DBDesigner 4, ou bien encore tester (sous windows uniquement pour le moment) son successeur MySQL Workbench, rendez-vous sur fabforce.net, vous y trouverez les fichiers d’installation, des captures d’écran et de la documentation.

Si vous connaissez d’autres outils intéressants disposant d’un module de « reverse engineering », partagez-les dans les commentaires, ils sont là pour ça.

Présentation

Si vous vous demandez à quoi elles peuvent bien servir, MySQL a dressé une liste pour vous :

Une certification est censée…
- Valider votre savoir-faire
- Diminuer les risques liés à la manipulation de MySQL
- Permettre d’offrir à son entreprise une plus grande qualité de service
- Augmenter la productivité
- Réduire les coûts de maintenance
- Offrir à son détenteur une augmentation de salaire

Au-delà de cette version légèrement idéaliste/marketing et en évitant par ailleurs l’aspect souvent « polémique » concernant les certifications (les « pour », les « contre »), ne cédons pas à la tentation du troll et voyons ce que MySQL nous propose.

Il existe aujourd’hui 4 certifications : « Associate » (CMA), « Developer » (CMDEV), « DBA » (CMDBA) et « Cluster » (CMCDBA).
Chacune d’elles vise un public souvent différent et nécessite l’obtention de un ou deux examens composés de 70 questions (sauf la « Associate » qui en compte 50).
Chaque examen est un QCM de 90 minutes (excepté la « Associate » : 60 min) dont les questions appellent de 1 à 5 réponses en général. Le « passing score » se situe autour de 43-45 / 70 environ.

Pour réserver un examen, MySQL renvoie vers les centres de passage Pearson Vue, leur site internet vous permet de repérer les centres de passage près de chez vous. Attention, tous ne sont pas listés sur le site, il se peut qu’un centre proche de vous propose en fait la certification mais ne soit pas visible… Si vous ne trouvez pas votre bonheur, à vous de contacter les centres de formation locaux, ce sont souvent ces types d’organisme qui font passer les certifications.

Une fois certifié (champagne !), et si vous le souhaitez, votre nom peut apparaître dans la liste des certifiés par pays, procédé similaire aux « pages jaunes » de Zend que certains d’entre vous connaissent peut-être.

Contrairement aux certifications Php (en tout cas à ce jour), avec MySQL vous repartez du centre d’examen avec le score détaillé de votre examen. Vos pourcentages de réussite sont affichés par chapitre. Ce type de statistiques permet de repérer ses faiblesses et évite de se demander pourquoi on a réussi ou pas l’examen… Quelque soit votre résultat vous visualiserez où sont vos forces et éventuelles faiblesses, c’est très appréciable.

Le tableau étant dressé, voyons dans le détail à quoi ressemblent ces certifications.

Dans le détail

- La certification « Associate »
Première étape vers une « reconnaissance » liée à MySQL, la certification « Associate » a pour mission de tester les candidats sur MySQL dans ses grandes lignes.
Les candidats devront prouver qu’ils connaissent les commandes de base SQL qui permettent de décrire une table, la supprimer, la vider…
Ils seront également interrogés sur les types de caractères disponibles, les jointures : consultez la liste détaillée sur le site de MySQL.
Retenez que la certification « Associate » est un sous-ensemble de la certification « Developer ».
La certification « Associate » requiert un seul examen, se déroule sur 60 minutes, comporte 50 questions et le score minimal à obtenir est d’environ 37 points.
Je n’ai personnellement pas passé celle-ci mais si c’est votre cas n’hésitez pas à nous en faire part dans les commentaires pour partager votre expérience.

- La certification « Developer »
Destinée aux développeurs ayant un minimum d’expérience avec MySQL, cette certification comporte deux examens de 70 questions. Vous aurez 90 minutes maximum pour venir à bout d’un examen. Obtenez au moins 43 bonnes réponses si vous voulez éviter les problèmes…
Voici une sélection de quelques thèmes parmi les plus représentés lors de l’examen :

Examen I

Le « client » mysql (à ne pas confondre avec le serveur « mysqld »), les types de données (un thème pas forcément sexy au premier abord mais nécessaire : gain de place, rapidité…), les tables et les index, les requêtes SQL : expressions SQL, requêtes de mises à jour, GROUP BY, UNION, etc.

Examen II

Les jointures, les sous-requêtes, les vues, les procédures stockées, les metadatas (INFORMATION_SCHEMA) et un soupçon d’optimisation.

Comme son nom l’indique, cette certification est particulièrement destiné aux développeurs qui manipulent MySQL régulièrement. Vous ne réussirez pas l’examen sans le préparer si vous faites « simplement » une petite requête de temps en temps au sein de vos scripts php par exemple. Je la conseille à tous ceux qui apprécient les diverses fonctionnalités de MySQL et qui ont envie d’aller plus loin. Préparer ces deux examens renforcera vos connaissances et vous apprendra forcément quelque chose, vous en sortirez plus polyvalents, pas forcément expert en procédure stockées mais au moins vous aurez appris à en manipuler quelques-unes et si besoin, le jour J, vous serez capables de les mettre en place rapidement.

Pour ceux qui comme moi viennent du monde du développement web, la partie I sera la plus simple, la partie II nécessite davantage de travail. On peut en effet être développeur internet depuis plusieurs années sans avoir codé la moindre procédure stockée… La gestion du temps sera également plus importante pour cette seconde partie, les questions étant plus longues et nécessitant davantage de réflexions que lors de la partie I. Je ne peux pas trop vous en dire vu que chaque candidat s’engage à ne pas communiquer sur le contenu des questions, mais vous avez l’idée générale.
Mes conseils pour se préparer aux certifications se trouvent en fin de ce billet.

- La certification « DBA »

Bienvenue aux administrateurs, et pour les autres : au boulot !
A l’instar de la certification « Developer », la « DBA » est du même type : deux examens de 90 min chacun, 70 questions, et un passing score d’environ 45/70.

Parmi les thèmes les plus représentés, on retrouve :
Examen I
Architecture de MySQL, configuration, démarrage et arrêt du serveur, la notion de verrouillage, les moteurs de stockage (une des parties les plus importantes, spécificités de MyISAM, InnoDB, Memory…), la maintenance des tables, les sauvegardes / restaurations.

Examen II
Gestion des utilisateurs (création, droits, etc), sécurité, optimisation de requêtes, optimisation de vos bases (selon vos moteurs de stockage), optimisation du serveur, montée en charge (étude de la réplication notamment…)

Comme vous le voyez les problématiques basculent pour la plupart dans un autre monde : celui de l’administrateur de bases de données. Cela dit, et ce fut une de mes motivations, il est également très intéressant lorsqu’on développe de connaître justement les différences entre les moteurs de stockage, comment jouer avec leurs forces et éviter leurs faiblesses dans un contexte donné par exemple.
On peut également considérer que l’optimisation des requêtes relève là encore du monde du développement mais c’est bien sûr un sujet qu’un DBA se doit de maîtriser.

Mon point de vue sur cette certification « DBA » : elle nécessite davantage de travail lorsqu’on vient du monde du développement, l’examen I notamment nécessite de se familiariser avec les (nombreux) outils existant sous MySQL pour effectuer des tâches de maintenance par exemple. Ces outils possèdent un bon nombre d’options, parfois spécifiques à un moteur de stockage et pour corser le tout plusieurs outils sont capables d’effectuer les mêmes traitements…

L’examen II est à mon sens beaucoup plus ludique, vous y trouverez moins d’outils à retenir mais quelques variables serveur notamment (tuning) sont à mémoriser. Ce second examen est vraiment tourné vers l’optimisation, je ne saurais trop vous conseiller de vous entraîner à manipuler un serveur MySQL en testant différentes configurations et d’observer par vous-même ce qui se trouve par exemple dans la documentation.

La certification Cluster

Au programme de celle-ci, un seul examen, 70 questions, 90 minutes et un passing score de 43/70 environ.
Complètement tournée vers le MySQL Cluster, cet examen ne sera validé que si vous êtes déjà certifié DBA. C’est logique après tout : difficile de se plonger au coeur du MySQL Cluster si l’on n’a pas une bonne connaissance du serveur MySQL « classique ».
MySQL conseille comme d’habitude d’avoir accumulé au moins un peu d’expérience en manipulant le cluster avant de se présenter à l’examen, (cf le paragraphe « Ma méthode »).

Parmi les principaux thèmes :
Architecture et organisation du cluster (vraiment spécifique par rapport à un serveur MySQL standard), le moteur de stockage NDB, les fichiers de configuration du cluster (config.ini, my.cnf, les options disponibles…), démarrage / arrêt / gestion du cluster, les sauvegardes / restauration, tuning, résolutions de problèmes.

Au vu des spécificités d’une installation cluster par rapport à une installation MySQL classique, il n’est pas possible de se reposer uniquement sur les connaissances MySQL évoquées lors des certifications précédentes pour s’en sortir lors de cet examen. Lire la documentation tout en testant systématiquement soi-même tout ce que vous lisez participera bien sûr à votre futur succès.

Comment se former ?

Il y’a différentes façons de faire, tout dépend de votre volonté, du temps dont vous disposez mais également de vos finances…

Les livres :

- Le « MySQL Certification Study Guide » couvre les certifications Associate, Developer et DBA, c’est celui que j’ai utilisé. Il comporte en fait deux grandes parties : « Developer » et « DBA », rappelons que la « Associate » est un sous-ensemble de la « Developer ».
Moins aride que la documentation, tout est organisé pour vous faciliter la vie pour la certification, c’est un excellent ouvrage qui vous renseignera au-delà des examens, c’est une très bonne source d’informations concernant MySQL 5.
Un de ces grands avantages : les exercices disponibles. Chaque chapitre dispose de son lot d’exercices (avec corrigés). Vraiment bien étudiés pour la certification, ces derniers sont un peu plus difficiles que lors de l’examen (ce qui est une bonne chose). A noter que le livre contient un CD contenant les pdf des différents chapitres et exercices.
Pour 40 euros environ c’est un ouvrage que vous devez vous procurer si vous envisagez une de ces trois certifications. Il contient de plus un bon de réduction de 20% sur le prix de votre premier examen (à vérifier, il existe une date de validité, renseignez-vous).
Seul point qui peut s’avérer négatif pour certains : le livre est en anglais… Cela dit, à aujourd’hui les certifications MySQL sont disponibles en deux langues : anglais et japonais, le choix est vite fait

- Pour les amateurs de cluster le « MySQL 5.1 Cluster Certification Study Guide » est là encore une aide très précieuse, c’est celui-ci que j’ai utilisé.
En anglais lui aussi, il se lit plus facilement que la documentation, comporte des exercices mais cette fois ni CD ni pdf, dommage mais pas dramatique. C’est un ouvrage que j’ai parcouru plusieurs fois avant l’examen et qui encore aujourd’hui me sert très souvent, son utilité dépasse le cadre de la certification : vous pouvez l’acheter tout simplement en tant que source d’informations sur le MySQL Cluster.

- Les formations :

Délivrées par différents organismes de formation (MySQL dispose également de cursus dédiés), ces formations se déroulent souvent sur plusieurs jours (2 à 5). Comptez jusqu’à 2000 euros environ pour une semaine de formation… Vu le tarif pratiqué ce sont des formations accessibles via son entreprise notamment, et pourquoi pas dans le cadre d’un DIF (Droit Individuel à la Formation), renseignez-vous auprès de votre entreprise.
Attention tout de même, si vous partez d’un niveau disons « standard » en MySQL le lundi matin 8h, et même après 5 jours de formation intensives, il n’est pas garanti que vous réussissiez le vendredi à 17h les deux examens requis pour une « Developer » ou une « DBA », il faut en effet du temps et de la pratique pour assimiler toutes les connaissances requises… Vous aurez évidemment gagné du temps dans cet apprentissage, sans aucun doute, mais le contenu est dense. Il est préférable de prendre son temps pour intégrer des connaissances plutôt que de se bourrer le crâne la veille de l’examen et en avoir oublié la moitié 48h après le jour J quelque soit le résultat.

N’ayant pas testé moi-même ces formations je ne peux vous en conseiller une en particulier, en revanche je vous encourage à partager vos impressions dans les commentaires si vous avez testé cette formule.

Ma méthode / Quelques chiffres

- Armé uniquement des livres cités ci-dessus (MySQL certification guide et Cluster certification guide), j’ai procédé par ordre. Je me suis tout naturellement intéressé d’abord à la « Developer » avant d’attaquer la « DBA » qui m’intéressait aussi (raisons citées plus haut) et enfin tout cela m’a donné envie de découvrir le cluster, que j’ai appris à connaître tout en préparant la certification.
- En ce qui concerne les examens « Dev » et « DBA » j’ai décidé de faire des fiches… Chaque partie fait en effet 300 pages, du coup j’ai pensé que résumer tout cela sur des fiches me permettrait de parcourir l’essentiel plus rapidement qu’avec un bloc 600 pages. C’est sans doute vrai mais la rédaction prend du temps, je dirais 50% du temps d’apprentissage d’un examen pour ma part.
- J’ai passé deux mois sur chaque examen de la « Dev ». Difficile de se faire une idée de ce que représentent vraiment deux mois, nous avons tous des plannings différents, des week-ends différents, mais cela donne un ordre d’idées, je n’avais pas de planning à tenir pour la « Dev » et la « DBA », j’ai donc fait ça pendant mon temps libre, sans me fixer une date.
- L’entraînement aidant, j’ai réduit la durée de préparation à un mois pour DBA I et 6 semaines pour DBA II.
- Concernant la « Dev » et la « DBA », j’ai d’abord étudié l’examen I, passé l’examen I, puis étudié l’examen II et passé l’examen II.
- Je n’ai pas fait de fiche pour la cluster, j’y ai consacré environ 2 mois.
- J’ai payé ma certification cluster 20$ au lieu de 200 euros lors de la conférence MySQL 2008 Les rabais sont importants lors de ce type d’évènements. Les certifications se déroulent alors sur papier, le score final n’est pas fourni, seul le résultat vous sera communiqué.
- Si vous avez choisi les livres cités plus haut : effectuez tous les exercices proposés, au moins une fois ou deux, ils vous préparent efficacement aux questions des examens.
- Testez, testez, testez ! Installez-vous un serveur MySQL, un cluster MySQL si besoin et testez par vous-même tout ce que l’on vous présente dans la documentation, vous ne devez pas tout connaître par coeur mais le minimum est de tout comprendre. Si vous êtes sous Windows passez pourquoi pas par Vmware pour vous installer des machines virtuelles hébergeant vos serveurs. Une fois la solution de Vmware installée, vous pouvez charger une Debian Etch par exemple et commencer vos installations / tests. Il est tout à fait possible à partir d’un seul pc de simuler plusieurs machines…

Impressions finales

- J’ai trouvé les examens Dev I et DBA II les plus simples, mon meilleur score fut d’ailleurs obtenu sur DBA II, le moins bon sur DBA I.
- Pour moi DBA I fut peut-être le moins drôle, pas mal d’outils/d’options à retenir, pour ceux qui ne sont pas déjà DBA MySQL il y’a du travail ici.
- Attention à la gestion du temps sur Dev II (cf le conseil de Giuseppe Maxia sur le jeu d’échecs dans les liens ci-dessous).
- J’ai adoré la partie DBA II (optimisations), c’est ludique, concret et sympa à apprendre, vous pouvez très rapidement appliquer ce que vous apprenez dans votre job.

Pour résumer mes impressions concernant ces certifications, elles m’ont beaucoup appris, elles vous « forcent » à parcourir de façon précise des domaines auxquels vous n’auriez peut-être pas été confronté de sitôt. Lorsque vous visez une certification, vous avez un objectif, on parcourt donc les documentations d’un autre oeil dans ces cas là…
Fort de ces nouvelles connaissances, vous aurez davantage de solutions à proposer face aux problèmes que vous rencontrerez.
Les certifications ne feront pas de vous des dieux vivants en MySQL mais des professionnels avertis, au fait des outils existant et capables de monter plus rapidement en compétence sur des sujets dont vous n’étiez pas forcément spécialistes.
Enfin, et c’est sans doute le plus important à mes yeux : les certifications aiguisent votre curiosité ! Lorsque j’ai démarré la certification « Developer », je ne pensais pas forcément passer la DBA, et encore moins la Cluster lors d’une conférence MySQL à Santa Clara

J’espère que ce retour d’expérience vous sera utile, si vous aussi vous avez passé une de ces certifications, laissez vos impressions dans les commentaires et faites en profiter la communauté !

Bien sûr, n’hésitez pas à poser ici vos questions concernant les certifications, j’y répondrai avec plaisir.

Quelques liens pour aller plus loin :

- Testez-vous ! MySQL vous propose 10 questions pour chacune des certifications dont nous venons de parler, les questions m’ont l’air un peu plus simples que celles des examens mais elles valent le coup néanmoins.
- Lisez aussi les conseils de Giuseppe Maxia pour la certification, ainsi que ceux de Mark Schoonover qui valent le détour également. Enfin le blog de Dave Stokes, il travaille chez MySQL dans l’équipe de certification.

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

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

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

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

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

A vos claviers