Pourquoi MySQL / InnoDB ne résolvent pas le problème
MySQL est l’un des piliers historiques de l’infrastructure web. Simple, largement documenté, facile à déployer, il reste un choix populaire. Pourtant, le moteur par défaut InnoDB, tout comme l’architecture globale de MySQL, porte les traces d’une époque révolue : la fin des années 90 et le début des années 2000, où les charges étaient simples, les réseaux locaux rapides et les environnements beaucoup moins distribués.
Cette note explique pourquoi MySQL/InnoDB se heurte aux mêmes obstacles que Postgres — parfois encore plus fortement — lorsqu’il s’agit de fonctionner dans des environnements contraints, instables ou distribués.
Un héritage architectural des années 90
MySQL a été pensé pour :
- des machines locales,
- des réseaux fiables,
- des workloads essentiellement en lecture,
- une faible concurrence en écriture.
Son évolution a amélioré ses capacités — notamment grâce à InnoDB — mais l’architecture reste marquée par cette origine.
Cette philosophie historique pose problème dès que les conditions ne sont pas optimales.
Limitations structurelles d’InnoDB
InnoDB apporte transactionnalité, MVCC et récupération après crash. Mais ces qualités s’appuient sur des mécanismes coûteux.
Le doublewrite buffer
Pour éviter la corruption lors d’une écriture partielle, InnoDB écrit chaque page deux fois :
Page modifiée
↓
Écriture dans le doublewrite buffer
↓
Écriture dans le tablespace final
Résultat :
- amplification d’écriture élevée,
- forte dépendance au débit du stockage,
- latence accrue dans les environnements lents.
Fragmentation et gestion des pages
Les mises à jour fréquentes fragmentent les pages InnoDB :
- pages partiellement remplies,
- index secondaires qui gonflent,
- purge nécessaire pour nettoyer les anciennes versions.
Ces opérations de maintenance consomment CPU et I/O — un problème majeur sur des machines contraintes.
Un moteur chargé en traitements d’arrière-plan
Pour fonctionner correctement, InnoDB dépend de nombreux threads internes :
- purge,
- flush du redo log,
- entretien du hash adaptatif,
- consolidation des modifications.
Sur un hardware limité, ces threads concurrencent directement l’application.
Réplication et cohérence : des limites profondes
La réplication MySQL est asynchrone par défaut :
Primaires → binlog → réplicas
Conséquences :
- décalage de réplication parfois important,
- incohérences temporelles entre nœuds,
- rattrapage difficile en cas de latence réseau.
La réplication semi-synchrone améliore partiellement la situation mais :
- augmente la latence des commits,
- dépend fortement de la stabilité du réseau,
- n’offre pas de cohérence stricte dans tous les cas.
MySQL n’a pas été conçu pour les réseaux intermittents ou multi-régions.
Scalabilité limitée hors cloud
Pour étendre MySQL horizontalement, il faut :
- du sharding manuel,
- des middlewares avancés (Vitess),
- des solutions cloud managées (Aurora, PlanetScale).
Ces solutions fonctionnent, mais elles :
- ajoutent des couches supplémentaires,
- nécessitent une expertise importante,
- supposent un réseau stable et des ressources suffisantes.
MySQL, par défaut, reste un système pensé pour une seule machine :
Scaling = ajouter CPU, RAM, SSD
Cette approche n’est pas viable dans des déploiements edge, en Afrique, ou dans des systèmes distribués local-first.
Conclusion
MySQL et InnoDB fonctionnent très bien dans leur cadre d’origine : serveurs centralisés, réseaux fiables, matériel puissant.
Mais leur architecture — doublewrite buffer, fragmentation, réplication asynchrone, scalabilité verticale — les rend inadaptés aux environnements contraints ou distribués.
Comprendre ces limites permet de savoir quand MySQL est un bon choix… et quand il devient un frein structurel.
Références recommandées
- Documentation MySQL — InnoDB Architecture
- Oracle Whitepaper — InnoDB: Design and Architecture
- Percona — InnoDB Performance Tuning
- MariaDB KB — Replication & Consistency
- Vitess — Sharding MySQL at Scale