1996 : c’est l’année de sortie initiale de MyISAM comme moteur de stockage de MySQL, conçu à une époque où la majorité des usages de bases de données restaient dominés par la lecture, avec peu d’écritures concurrentes à gérer simultanément.
Ce billet retrace, pour les administrateurs curieux de comprendre l’origine d’une recommandation aujourd’hui bien établie, les raisons techniques qui ont poussé l’écosystème MySQL, puis WordPress, à s’éloigner de MyISAM au profit d’InnoDB. Il ne traite pas de la procédure de migration d’une base existante d’un moteur à l’autre, déjà détaillée ailleurs.
Le verrouillage de table, principale limite de MyISAM
MyISAM applique un verrouillage au niveau de la table entière lors de toute opération d’écriture : une insertion, une mise à jour ou une suppression bloque l’accès en écriture à l’intégralité de la table concernée, y compris pour des lignes totalement indépendantes de celle en cours de modification. Sur un usage majoritairement en lecture, cette contrainte reste peu perceptible ; elle devient un goulet d’étranglement dès que le nombre d’écritures concurrentes augmente.
Un site WordPress moderne, avec ses commentaires, ses statistiques de consultation stockées en base, ses extensions de cache d’objet qui écrivent régulièrement des transitoires dans wp_options, génère justement ce profil d’écritures concurrentes que MyISAM gère mal comparé à un moteur conçu spécifiquement pour ce cas.
InnoDB et le verrouillage au niveau de la ligne
InnoDB, intégré à MySQL depuis ses premières versions mais longtemps proposé en option plutôt qu’en moteur par défaut, applique un verrouillage bien plus fin, au niveau de la ligne concernée plutôt que de la table entière. Deux écritures simultanées sur deux lignes différentes d’une même table peuvent ainsi s’exécuter en parallèle sans se bloquer mutuellement, un gain déterminant sur des tables à fort trafic d’écriture concurrente.
- InnoDB ajoute également la prise en charge des transactions, absente de MyISAM, permettant de regrouper plusieurs opérations et de les annuler entièrement en cas d’échec partiel.
- InnoDB introduit les contraintes de clé étrangère, garantissant l’intégrité référentielle entre tables liées, une fonctionnalité que MyISAM n’a jamais proposée nativement.
MySQL 5.5, le tournant qui précède WordPress
Le changement décisif est survenu avec la sortie de MySQL 5.5, qui a fait d’InnoDB le moteur de stockage par défaut pour toute nouvelle table créée sans moteur explicitement spécifié. Cette décision de l’équipe MySQL elle-même précède largement toute recommandation propre à WordPress : elle reflète un constat général de l’écosystème des bases de données relationnelles, valable bien au-delà du seul cas des sites de gestion de contenu.
WordPress a suivi ce mouvement plutôt que de l’initier : les nouvelles installations créent leurs tables avec InnoDB depuis que la valeur par défaut de MySQL elle-même a changé, et la documentation officielle du projet recommande la migration des bases plus anciennes encore sur MyISAM vers InnoDB, en cohérence avec cette évolution générale de l’écosystème.
Un moteur qui reste pertinent dans des cas marginaux
MyISAM n’a pas totalement disparu de l’usage : certaines tables très spécifiques, en lecture quasi exclusive et à faible fréquence d’écriture, peuvent encore en tirer un léger avantage de performance brute sur des opérations de lecture simple, en l’absence de verrouillage fin à gérer. Ce cas reste toutefois marginal sur une base WordPress standard, où la majorité des tables mélangent lecture et écriture de façon suffisamment fréquente pour qu’InnoDB reste le choix pertinent par défaut.
Ce que cet historique change concrètement pour un hébergeur aujourd’hui
Un hébergeur qui reprend un parc de sites anciens peut encore rencontrer des tables MyISAM héritées d’installations très anciennes, jamais migrées depuis leur création initiale. Comprendre l’origine historique de cette recommandation aide à en expliquer clairement l’intérêt à un client réticent, plutôt que de présenter la migration comme une simple case à cocher sans justification technique.
Comprendre pourquoi une recommandation existe permet de l’expliquer avec conviction ; l’appliquer sans en connaître l’origine ne convainc jamais durablement un client sceptique.
En résumé
Le passage recommandé de MyISAM vers InnoDB sur une base WordPress ne découle pas d’une décision propre au projet, mais d’une évolution plus large de l’écosystème MySQL, initiée dès la version 5.5 avec le changement de moteur par défaut. Le verrouillage au niveau de la ligne plutôt que de la table entière reste l’argument technique central de cette évolution, particulièrement pertinent sur des sites à fort volume d’écritures concurrentes comme le sont la plupart des installations WordPress modernes.
