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.

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

C’est plutôt facile, et je fournis trois solutions pour la peine :

1. Avoir un fichier de configuration pour le script accessible seulement par l’utilisateur privilégiéOn définit dans le fichier de configuration des variables d’environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu’à utiliser la commande source pour récuperer ses variables (seul l’utilisateur privilégié pourra lire le fichier). Simple et efficace.
2. Avoir un fichier de configuration pour mysql accessible seulement par l’utilisateur privilégiéVariante de la précédente : on crée un fichier de configuration spécifique pour mysql (que l’on pourra mettre par exemple dans /etc/mysql mais il n’y a aucune obligation). Et on utilise l’option –defaults-file pour que mysql lise le contenu du fichier (il lit notamment les sections [client] et [mysql]). Exemple de fichier:
   
[client]
host = localhost
user = votre_user
password = votre_mot_de_passe
socket = /var/run/mysqld/mysqld.sock

   Bonus : on peut spécifier d’autres options pour influer sur mysql (en vrac, le nom de serveur, le jeu de caractères…).
3. Pour ceux qui ont plusieurs scripts mais qui ont des options qui diffèrent légèrementVous avez des scripts quasiment identiques mais les options diffèrent légèrement (ou vous voulez centraliser tout en un seul fichier) : c’est possible. C’est une variante du cas précedent : on écrit un fichier de configuration mysql que l’on découpe en plusieurs sections. Ensuite, on fait appel au programme my_print_defaults ! my_print_defaults examine le fichier de configuration (option -c pour spécifier le votre…) et donne en sortie les paramètres à passer à mysql sous forme d’argument. Exemple :
   
$ my_print_defaults -c /etc/mysql/maconf.cnf client
--host=localhost
--user=votre_user
--password=votre_mot_de_passe
--socket=/var/run/mysqld/mysqld.sock

   Il ne reste plus qu’à passer cela à mysql en récuperant la sortie dans une variable (ou en utilisant cette petite merveille de xargs).