Pourquoi MySQL / InnoDB ne résolvent pas le problème

MySQL est un pilier de l’infrastructure web depuis plus de vingt ans. Son omniprésence, sa simplicité et son écosystème communautaire en ont fait un choix naturel pour les applications web traditionnelles. Mais MySQL — et plus spécifiquement son moteur de stockage par défaut, InnoDB — a été conçu dans une époque très différente : la fin des années 1990 et le début des années 2000, lorsque le matériel, l’architecture réseau et les charges applicatives n’avaient rien à voir avec celles d’aujourd’hui.

Cette note explique pourquoi MySQL/InnoDB rencontre des difficultés dans des environnements contraints ou distribués, pourquoi ses fondations architecturales limitent sa capacité d’adaptation, et pourquoi il ne peut pas répondre pleinement aux défis des déploiements modernes local-first, CPU-first ou fonctionnant sur des réseaux peu fiables.

Héritage architectural des années 1990

MySQL a démarré comme une base légère et rapide, optimisée pour des workloads simples, fortement orientés lecture. Avec le temps, le système a évolué, mais ses racines de conception restent visibles :

• hypothèses de serveurs stables avec stockage directement attaché (direct-attached storage),
• faible concurrence en écriture,
• réseaux locaux prévisibles,
• workloads centrés sur l’indexation et les requêtes ponctuelles (point queries).

Même InnoDB, introduit plus tard comme moteur transactionnel, prolonge cette philosophie initiale.

L’architecture d’origine de MySQL privilégiait la simplicité et la vitesse plutôt que la robustesse et la scalabilité. Si cela était parfaitement adapté au web de 2003, cela devient problématique pour les systèmes distribués modernes et les déploiements edge contraints.

Limites d’InnoDB

InnoDB a introduit les transactions ACID, le MVCC et la reprise après crash — des améliorations majeures par rapport à l’ancien moteur MyISAM. Mais la manière dont ces fonctionnalités sont implémentées introduit des contraintes structurelles.

Le doublewrite buffer

InnoDB ne peut pas s’appuyer uniquement sur l’OS ou le système de fichiers pour garantir l’atomicité. Pour éviter la corruption en cas d’écriture partielle, il utilise un doublewrite buffer :

Page modifiée
↓
Écriture de la page dans le doublewrite buffer
↓
Réécriture de la page dans le tablespace final

Ce mécanisme double certaines opérations d’écriture, augmentant l’amplification d’écriture (write amplification) et la pression I/O. Ce qui devient problématique dans des environnements où le débit disque est limité.

Fragmentation et gestion des pages

InnoDB stocke les données sous forme de pages, mais des mises à jour et suppressions fréquentes provoquent de la fragmentation :

• pages faiblement remplies,
• croissance excessive des index secondaires,
• opérations de purge nécessaires pour nettoyer les anciennes versions de lignes.

Cela entraîne une croissance de stockage difficile à prévoir et des besoins de maintenance périodique qui entrent en concurrence avec la charge principale.

Traitements de fond lourds

Pour maintenir la cohérence et les performances, InnoDB s’appuie sur :

• des threads de purge en arrière-plan,
• la maintenance de l’adaptive hash index,
• le change buffering,
• le flush des redo logs.

Sur des CPUs limités, ces opérations de fond peuvent entrer en compétition avec les requêtes applicatives, augmentant la variabilité de latence.

Réplication et défis de cohérence

Par défaut, la réplication MySQL est asynchrone :

Primary → binary log → replica

Ce qui provoque du lag de réplication, en particulier en cas de fort volume d’écriture ou de forte latence réseau. Dans des environnements distribués ou WAN, ce lag devient :

• imprévisible,
• incohérent entre réplicas,
• difficile à quantifier côté application.

Il existe une réplication semi-synchrone, mais elle :

• augmente la latence des commits,
• ne garantit toujours pas une cohérence stricte dans tous les cas,
• dépend fortement des performances réseau.

MySQL a été conçu pour des setups mono-région, pas pour des réseaux globaux ou intermittents.

Scalabilité limitée hors du cloud

La scalabilité horizontale de MySQL nécessite généralement :

• du sharding manuel,
• du middleware (Vitess, ProxySQL),
• des solutions cloud spécifiques (Aurora, PlanetScale),
• une expertise opérationnelle que beaucoup d’équipes n’ont pas.

Ces systèmes fonctionnent — mais ils sont construits au-dessus de MySQL, pas nativement intégrés au moteur. Et ils supposent :

• un réseau fiable,
• plusieurs nœuds stables,
• des opérateurs capables de gérer failover et recovery.

Pour les petites équipes, les déploiements edge, ou les environnements à infrastructure faible, ces hypothèses ne tiennent plus.

Le comportement par défaut de MySQL reflète toujours une architecture mono-nœud où :

Scaler = machine plus grosse, SSD plus rapide, plus de RAM

Cette approche est inadaptée dans les environnements local-first ou « distribués par nécessité ».

Conclusion

MySQL et InnoDB sont des outils puissants lorsqu’ils sont utilisés dans le contexte pour lequel ils ont été conçus : des serveurs centralisés avec matériel et réseaux fiables. Mais leurs fondations architecturales — doublewrite buffering, fragmentation des pages, réplication asynchrone et hypothèses de scalabilité mono-nœud — les rendent mal adaptés aux environnements contraints, aux réseaux instables ou aux workloads distribués.

Comprendre ces limites est essentiel pour décider si MySQL convient à un workload donné, ou pour explorer des architectures alternatives optimisées pour des environnements contraints et distribués.

Références recommandées

1. Documentation MySQL — InnoDB Architecture
2. Oracle Whitepaper — InnoDB: Design and Architecture
3. Percona — InnoDB Performance Tuning
4. MariaDB KB — Replication & Consistency
5. Vitess — Sharding MySQL at Scale