Audit et optimisation MySQL 5

Ca faisait un moment que je devais écrire un post sur cet excellent livre. Mais à chaque fois, je me trouve d'autres occupations. Profitant donc d'un peu de temps libre, voici mon avis sur ce livre destiné aux administrateurs.
Bon, il est vrai que le livre a été édité en mars 2010, avant l'acquisition de MySQL par ORACLE et que depuis, il a coulé beaucoup d'eau sous les ponts. Mais, il n'en demeure pas moins une excellente référence pour tous les administrateurs qui n'ont malheureusement pas le temps d'approfondir leur connaissance suite à une surcharge de travail.

Ce que j'ai particulièrement apprécié dans ce livre c'est son positionnement. Enfin un livre qui répond aux questions qu'on se pose lorsque l'on doit auditer ou optimiser une base ou le schéma d'une base, lorsque l'on doit faire face à une situation d'urgence suite à un accroissement de requêtes lors d'un burst.

Chapitre 1 : Il est essentiellement consacré à la gestion des situations d'urgences. Il est bien évident, que toutes les situations ne peuvent pas être traitées, mais on sent le vécu et l'expérience des auteurs au travers des exemples et astuces qu'il nous prodigue. Cela a été très instructif. Même si je n'ai pas eu souvent de situations catastrophiques à gérer, c'est toujours intéressant de savoir comment réagir lorsqu'un imprévu se présente.

Chapitre 2 : Ce chapitre est consacré au choix de son (ses) serveur(s) pour l'hébergement de son instance de MySQL. Cette partie, même si elle décrit les grands axes permettant de faire ses propres choix, elle reste pour moi trop généraliste. J'aurai aimé voir apparaitre le traitement de cas concrets en terme de dimensionnement, de configuration système, de paramétrage spécifique du noyau, du paramétrage des différentes variables de MySQL. Mais bon, c'est déjà bien d'avoir abordé ce sujet dans un livre? Peut-être que la prochaine édition sera beaucoup plus prolixe sur ce sujet ?

Chapitre 3 : Enfin !! un livre qui ose aborder dans le détails les différents moteurs de stockage de MySQL. Historiquement, n'ayant pas besoin de transaction dans les applications que je développe, je me suis toujours contenté du moteur de stockage par défaut qui est MyISAM. Avec le temps, je me suis aussi habitué aux outils me permettant (mysqlcheck) de réparer ou de corriger mes bases. De plus (touchons du bois) à ce jour, je n'ai eu aucune raison valable et sérieuse d'en changer :

• les performances sont très satisfaisantes, 
• j'ai pratiquement aucune erreur, 
• je n'ai jamais eu de pertes de données.

Mais il était intéressant de voir quels étaient les différents moteurs de stockages et de pouvoir imaginer quel moteur choisir en fonction du type d'utilisation de l'application développée. 

A suivre...