Quelle est la différence avec un forum? Nous retenons les meilleures questions et nous écrivons un article avec la dite question et sa réponse. Si vous ne voyez pas votre question, c’est que nous n’avons pas encore eu le temp d’y répondre…

A très bientôt!

PS: Cette adresse peut aussi être utilisée si vous constatez un problème sur le site…

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 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é pendant encore longtemps. 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

A l’origine de cette division, des rythmes de développement différents entre MySQL Server et MySQL Cluster, mais aussi des retours de la part des utilisateurs du cluster indiquant que ces derniers sont davantage concernés par les derniers développements du MySQL Cluster plutôt que par ceux du MySQL Server. Cette séparation devrait donc permettre aux nouvelles versions de MySQL Cluster d’être publiées plus rapidement.

Jeremy Cole apporte son grain de sel à cette annonce et souligne que cette séparation dans les packages peut également être percue comme un “aveu” que le système actuel permettant à MySQL d’accueillir des moteurs “plugable” ne tient peut-être pas toutes ses promesses… Ce que reconnaît à demi-mot Stewart Smith (MySQL software engineer sur le cluster) dans les commentaires : l’opération n’est apparemment pas simple, les moteurs de stockage (NDB compris) effectuant selon lui plus de tâches qu’ils ne devraient.

- J’attendais mon édition de High Performance MySQL 2nd edition pour la semaine prochaine, le 1er juin d’après le mail récapitulatif de précommande reçu fin avril, mais c’est la date du 1er juillet qui apparaît désormais sur la fiche d’Amazon France… Le .com indique en revanche la date du 19 juin, un peu flou tout ça.
Ceux qui comme moi sont impatients de découvrir cette seconde édition (l’ancienne datait de 2004 et était déjà excellente) devront donc patienter encore un peu.
D’ici là libre à vous de la précommander ou d’attendre mon verdict… qui ne pèsera sans doute pas grand chose face à la qualité des auteurs présents : les experts du fameux “mysqlperformance blog” (Baron Schwartz, Peter Zaitsev, Vadim Tkachenko), mais aussi Jeremy Zawodny (de la précédente édition), Arjen Lentz… Du beau linge !

- La véritable mauvaise nouvelle est ailleurs, il s’agit bien sûr de la fermeture de la filiale française d’O'Reilly survenue au début du mois, un évènement pas si hors-sujet sur un blog comme celui-ci : qui n’a jamais eu entre les mains un de leurs ouvrages ?
En dépit de la qualité reconnue de ces derniers, la maison mère a fini par couper les subventions : les faits sont relatés sur immateriel.fr (billet du 9 mai), un blog tenu par l’ancienne équipe semble-t-il. Souhaitons leur tout le succès qu’ils méritent dans leurs prochaines aventures.

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

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

L’index B-TREE

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

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

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

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

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

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

Le HASH index

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

InnoDB et l’ADAPTIVE HASH INDEX

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

A retenir :

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

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

Afin d’avoir recours le moins possible aux disques, l’utilisation des index est une première étape qu’on complètera par différents mécanismes de caching afin de limiter encore davantage les accès à ce support et éviter ainsi que le disque ne constitue un goulet d’étranglement (”I/O bound”).

Outre ces mécanismes, la technologie SSD pourrait bien à l’avenir changer la donne.

Les SSD, littéralement Solid-State Drives (ou Disk par abus de langage), ne sont pas des disques mais des unités de stockage constituées de mémoire flash (persistante).

Au vu des benchmarks les concernant, il y’a fort à parier que les SSD seront de plus en plus d’actualité dans les mois qui viennent.
Ces benchmarks sont unanimes sur un point : les SSD obtiennent d’excellentes performances lors des random read, laissant loin derrière les disques “classiques”. Grosse ombre au tableau néanmoins : les tests effectués sur des random write ne sont pas aussi concluants. Pourquoi ?

Sur un disque classique un “random read” entraîne (du plus couteux au moins couteux) :
- le déplacement de la tête de lecture/écriture sur la bonne piste (”seek time”)
- une fois la tête sur la bonne piste, il faut encore repérer sur celle-ci le bloc secteur demandé (”rotational latency”)
- la lecture et la transmission de la donnée vers le système.

Avec un SSD, le même “random read” est beaucoup plus rapide : pas de tête de lecture à déplacer ni d’attente liée à la rotation d’un plateau. Conclusion, comptez environ 5 ms de temps d’accès à un secteur particulier pour un disque performant et environ 0.15 ms pour un SSD.

En revanche, lors d’une écriture, le SSD est par conception beaucoup plus lent qu’en lecture : la “préparation” obligatoire de l’importante zone dédiée à l’écriture (”erase block”) et un ensemble d’écritures spécifique à cette technologie pénalisent les performances.

Face à ce problème connu, des parades logicielles voient le jour et la plupart des constructeurs de SSD proposeront sûrement leur propre solution dans les mois à venir. Actuellement la technologie MFT (Managed Flash Technology) offre déjà de grandes améliorations (cf lien “benchmarks” ci-dessus, 3ème graphique). Les performances obtenues sont sensiblement égales lors des random read par rapport aux SSD classiques mais les résultats sont 30x supérieurs en random write par rapport aux SSD et 15x supérieurs aux disque durs.

Enfin, un autre signe que le SSD est très certainement une technologie d’avenir : un des plus récents moteurs pour MySQL, PBXT, est conçu pour fonctionner avec les SSD (pdf).

Pour résumer, concernant les SSD :

Avantages :
- Très rapide en random read
- Peu sensible à la fragmentation des fichiers : performances constantes.
- Fiabilité supérieure au HD (pas d’éléments mécaniques en mouvement)

Inconvénients des SSD :
- Prix
- Capacités en deça des disques actuels
- Durée de vie plus courte qu’un disque (nombres de cycles d’écriture limités)

Améliorations attendues (et en cours) :
- Chute des prix
- Augmentation des performances en écriture
- Augmentation de la capacité
- Meilleure répartition des écritures sur le support (augmentation du nombre de cycles écritures / durée de vie)

Si cette rapide présentation des SSD a aiguisé votre curiosité, voici quelques pistes pour aller plus loin :
- Le blog de Kevin Burton.
- La rubrique SSD sur Wikipédia (notamment les références en bas de page).