Moteur de stockage MySQL : InnoDB par défaut, et les rares exceptions

Entre MyISAM, InnoDB ou MEMORY, quel engine choisir pour une base MySQL ? InnoDB, le moteur de stockage par défaut, pour presque toute table d'un site web : transactions, verrouillage par ligne, aucune donnée perdue après un crash du serveur. MEMORY sert à une donnée jetable, MyISAM à une archive figée.

Quel moteur de stockage choisir pour MySQL ?

Le moteur de stockage InnoDB convient à la quasi-totalité des tables d'un site internet : articles, comptes, commandes, commentaires, réglages. Le manuel de MySQL 8.4 le présente comme le moteur généraliste recommandé, et CREATE TABLE l'emploie dès qu'aucune clause ENGINE n'est précisée. Choisir une autre solution relève donc de l'exception, et une exception se justifie table par table, jamais pour une base entière.

Une même base accepte en effet plusieurs moteurs : chaque table déclare le sien. C'est ce qui explique qu'un ancien site garde quelques tables MyISAM créées il y a quinze ans à côté de tables InnoDB ajoutées par une extension récente. La décision se prend donc structure par structure, selon trois questions : les données doivent-elles survivre à un redémarrage, plusieurs visiteurs modifient-ils le contenu en même temps, et une modification partielle serait-elle grave ? Cette évaluation vaut pour tout hébergement, et le comparatif entre un hébergement mutualisé et un VPS détaille ce que chaque formule laisse régler soi-même.

Blog, vitrine ou boutique : InnoDB sans discussion

Pour un CMS, une boutique ou une application métier, utiliser InnoDB n'a rien d'une préférence : c'est la seule option qui protège une commande à moitié enregistrée. Le code PHP d'une boutique regroupe dans une transaction l'insertion de la commande, de son détail et la mise à jour du stock ; si l'une échoue, ROLLBACK annule le tout. Avec MyISAM, les enregistrements déjà passés restent en base, l'intégrité de la commande n'est plus garantie, et l'incohérence se découvre au prochain inventaire.

Table de cache ou de sessions : MEMORY sous conditions

Le moteur MEMORY se défend pour des données que l'on sait reconstruire : un cache de résultats, une table de correspondance rechargée par un script au démarrage, un compteur temporaire. Il garde les enregistrements en RAM, sans rien poser sur le disque dur. La contrepartie est brutale : un redémarrage de MySQL vide la table, seule sa structure subsiste.

Archive figée héritée : MyISAM toléré

Une table MyISAM que personne ne modifie plus, consultée de temps en temps, peut rester telle quelle si la conversion n'apporte rien et prend des heures. Dès qu'une application recommence à y écrire, la question se repose, et la réponse redevient InnoDB.

Quelle est la différence entre MyISAM et InnoDB ?

MyISAM et InnoDB diffèrent d'abord par leur rapport à la cohérence : InnoDB est un moteur transactionnel conforme au modèle ACID, MyISAM ne l'est pas. Le premier garantit qu'une suite d'opérations passe en entier ou pas du tout ; le second exécute chaque requête isolément, sans retour arrière possible. Tout le reste découle de cette différence de conception, y compris le comportement sous charge et après un arrêt brutal.

Les principaux écarts entre les trois engines, critère par critère :

Transactions et verrouillage au niveau de la ligne

InnoDB pose ses verrous au niveau de la ligne : quand un visiteur met à jour son panier, seule cette ligne se bloque, et les autres requêtes continuent de lire et de modifier le reste de la table. MyISAM verrouille la table entière à chaque modification, et une lecture longue bloque à son tour les mises à jour : une seule requête MySQL avec LEFT OUTER JOIN mal optimisée suffit à figer une page de commentaires. Sur un site peu fréquenté, l'écart passe inaperçu ; sur un forum ou une boutique en période de soldes, les requêtes s'empilent derrière chaque UPDATE et le temps de réponse grimpe. MyISAM compense en partie avec les insertions concurrentes (concurrent_insert), qui ajoutent des lignes en fin de fichier pendant une lecture, mais seulement tant que le fichier ne comporte pas de trous laissés par des suppressions.

Ce que chaque moteur écrit sur le disque dur

Sous Linux, le répertoire de données se trouve en général dans /var/lib/mysql, avec un sous-dossier par base. Une table MyISAM y occupe deux fichiers : .MYD pour les lignes et .MYI pour les index. Une table InnoDB tient dans un fichier .ibd propre, l'option innodb_file_per_table étant active par défaut depuis MySQL 5.6, auquel s'ajoutent l'espace système ibdata1, les journaux d'annulation et le redo log, dont MySQL 8.0.30 a regroupé les fichiers dans le dossier #innodb_redo. Une table MEMORY, elle, ne laisse sur disque que sa définition.

Le redo log explique cette fiabilité : chaque modification y figure avant d'atteindre le fichier de données. Après une coupure de courant, le moteur rejoue ce journal au démarrage et retrouve un état cohérent sans intervention. MyISAM, lui, marque la table comme « crashed » et attend un REPAIR TABLE ou un passage de myisamchk, avec un risque réel de lignes perdues.

Pourquoi InnoDB a remplacé MyISAM comme moteur par défaut

InnoDB a pris la place de MyISAM avec MySQL 5.5.5, en 2010, quand Oracle a jugé cette solution transactionnelle assez mûre pour l'usage général. Les deux grandes étapes suivantes ont retiré à MyISAM ses derniers arguments. MySQL 5.6 a ajouté à InnoDB les index FULLTEXT, donc l'indexation de texte qui justifiait jadis de rester sur MyISAM pour la recherche interne d'un site web. MySQL 5.7 a ajouté les index spatiaux, autre fonctionnalité longtemps réservée à MyISAM.

MySQL 8.0 a franchi un pas décisif : le dictionnaire de données vit désormais dans des tables InnoDB transactionnelles, les fichiers .frm ont disparu et les tables système du schéma mysql sont passées en InnoDB. Le partitionnement natif n'existe plus que pour InnoDB et NDB. MyISAM reste disponible, mais sa gestion ne reçoit plus de fonctionnalité notable.

Le tampon mémoire, le buffer pool, a fait tomber l'argument de la vitesse. Il garde en RAM les pages de données et d'index les plus lues ; sur une machine dédiée, on lui attribue souvent la majeure partie de la mémoire disponible via innodb_buffer_pool_size. Une base dont l'essentiel tient dans ce tampon répond à des lectures presque aussi vite qu'une table en RAM, sans perdre ses données au redémarrage.

Côté MariaDB, le parcours est comparable : le choix par défaut y reste InnoDB, repris de MySQL depuis MariaDB 10.2 à la place de l'ancien fork XtraDB. MariaDB ajoute Aria, qui reprend l'esprit de MyISAM avec une meilleure résistance aux pannes ; MariaDB s'en sert pour ses tables système et ses tables temporaires internes sur disque, mais les tables applicatives gagnent à rester en InnoDB.

Quand utiliser MyISAM plutôt qu'InnoDB ?

MyISAM ne se justifie plus que dans quelques situations étroites, presque toutes liées à de l'existant. Avant de créer une table MyISAM neuve, il faut pouvoir citer une fonction qu'InnoDB n'offre pas et dont l'application a réellement besoin. Les cas qui reviennent sur les forums d'administration sont peu nombreux.

• Le compteur instantané. Une table MyISAM stocke son nombre exact de lignes : SELECT COUNT(*) FROM t sans WHERE répond sans rien lire. InnoDB doit parcourir un index, car chaque transaction peut voir un nombre différent de lignes. Une page qui affiche ce total à chaque visite gagne plus à le mettre en cache qu'à garder MyISAM.
• L'AUTO_INCREMENT par groupe. Sur une clé composée, MyISAM sait numéroter la seconde colonne séparément pour chaque valeur de la première (1, 2, 3 par catégorie). L'autre engine ne le fait pas ; une application utilisant ce mécanisme doit calculer ce numéro elle-même avant de changer de moteur.
• Les tables MRG_MyISAM. Le moteur MERGE, affiché MRG_MyISAM, présente plusieurs tables MyISAM identiques comme une seule, par exemple un journal découpé par mois. Le partitionnement d'InnoDB remplit ce rôle de façon plus propre.
• L'archive en lecture seule. Une table figée, compressée avec myisampack, occupe peu de place et ne craint pas grand-chose puisque personne n'y écrit.

Hors de ces cas, garder MyISAM revient à cumuler les inconvénients, verrous de table et réparations après crash, sans avantage en retour. Sur un hébergement mutualisé, le risque se voit concrètement : une table de sessions MyISAM marquée « crashed » après une coupure suffit à faire échouer chaque page générée en PHP, jusqu'à la réparation.

MEMORY, un moteur rapide mais volatil

Le moteur MEMORY, anciennement appelé HEAP, garde tout son contenu en mémoire vive, ce qui le rend très rapide pour des recherches par égalité grâce au hachage. Sa limite principale tient à sa nature : au redémarrage du serveur MySQL, la table existe toujours mais se retrouve vide. Il ne convient donc qu'à des données que l'application sait recréer.

Ses autres contraintes surprennent souvent ceux qui l'adoptent pour gagner en vitesse :

• aucune colonne TEXT ni BLOB ;
• un format de ligne fixe : un VARCHAR(255) réserve sa longueur maximale pour chaque ligne, ce qui gonfle l'occupation en RAM ;
• une taille bornée par max_heap_table_size, fixé à 16 Mo par défaut ; au-delà, l'insertion échoue avec l'erreur « The table is full » ;
• un verrouillage par table, comme MyISAM, qui pénalise les mises à jour simultanées ;
• aucune transaction et aucune clé étrangère.

MySQL 8.0 a d'ailleurs abandonné MEMORY pour ses propres tables temporaires internes : TempTable s'en charge par défaut, car il gère les colonnes de longueur variable et les champs BLOB. Pour une table de cache applicatif, une table InnoDB servie depuis le buffer pool offre souvent des performances proches sans les limites de mémoire ni le risque de perte. Cette solution reste un outil de niche, utile dans des cas précis, pas une option de performance générale.

Comment convertir MyISAM en InnoDB sans casser le site ?

Convertir une table MyISAM en InnoDB tient en une instruction ALTER TABLE, mais la migration se prépare : la méthode commence par repérer les tables concernées dans la base du site, puis à vérifier qu'aucune n'utilise une fonction propre à MyISAM.

SELECT table_name, engine, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE() AND engine <> 'InnoDB';

Cette requête liste chaque table qui n'est pas en InnoDB, avec une estimation de son volume. On passe ensuite les tables MySQL en InnoDB une par une, en remplaçant wp_posts par le nom de chaque table :

ALTER TABLE wp_posts ENGINE = InnoDB;

MySQL recopie alors toute la table dans le nouveau format. Sur plusieurs gigaoctets, l'opération dure et réclame un espace libre au moins égal à la taille de la table. Une procédure prudente suit cet ordre :

1. exporter la base complète avec mysqldump ou l'export de phpMyAdmin, et garder le fichier hors du serveur ;
2. contrôler les tables marquées « crashed » avec CHECK TABLE et les réparer d'abord, car une table abîmée se convertit mal ;
3. tester la conversion sur une copie de développement quand le code est complexe ;
4. lancer la conversion en heure creuse, en commençant par les plus petites tables ;
5. comparer le nombre d'enregistrements avant et après ;
6. vérifier que default_storage_engine vaut bien InnoDB, sinon les tables créées par une future extension repartiraient sur l'ancien moteur.

Sur un hébergement mutualisé sans accès en ligne de commande, phpMyAdmin propose la même opération : onglet « Opérations » de la table, champ « Moteur de stockage », puis exécution. Le passage de MyISAM vers InnoDB d'une base WordPress de taille ordinaire prend quelques secondes par table. Deux blocages reviennent souvent : une clé trop longue sur une colonne utf8mb4 (InnoDB accepte 3072 octets par clé avec le format de ligne DYNAMIC, 767 avec les anciens formats) et un index FULLTEXT sur une installation antérieure à MySQL 5.6. Une fois la migration terminée, une instance que l'on administre soi-même offre aussi la possibilité d'ajuster le buffer pool au volume des données converties.

Comment gérer une base qui mélange tables MyISAM et InnoDB ?

Une base mixte, avec des tables MyISAM et InnoDB côte à côte, fonctionne, mais ses transactions ne protègent que la partie InnoDB. Si une requête modifie une table de chaque moteur puis échoue, ROLLBACK annule la modification InnoDB et laisse en place celle de MyISAM : MySQL émet seulement un avertissement indiquant que certaines modifications non transactionnelles ne peuvent pas être annulées. Les jointures entre les deux restent possibles, avec le verrou de table de MyISAM qui ralentit l'ensemble dès qu'une modification intervient.

Les sauvegardes souffrent aussi du mélange. L'option mysqldump --single-transaction produit un export cohérent sans bloquer le site, mais uniquement pour les tables InnoDB ; les tables MyISAM exigent un verrou de lecture pendant l'export. Le binary log, qui sert à la réplication et à la restauration à un instant précis, enregistre bien les deux moteurs, mais une écriture MyISAM au milieu d'une transaction peut produire un réplica différent de la source.

Les fonctions avancées tirent elles aussi vers InnoDB. Les déclencheurs fonctionnent avec les deux engines, mais seul InnoDB annule l'écriture d'un trigger quand la requête qui l'a lancé échoue, comme le détaille la page sur l'écriture des triggers de MySQL. De même, le type JSON se combine mieux avec les index et les colonnes générées d'InnoDB, une raison de plus pour ne pas ranger du JSON dans un BLOB. La conclusion pratique reste la même : une base mixte se traite comme un état transitoire, à résorber.

Cinq idées reçues sur MyISAM ou InnoDB encore lues sur les forums

Le débat MyISAM ou InnoDB traîne des arguments datés de MySQL 5.1, que l'on retrouve encore dans de vieux tutoriels. Les vérifier avant d'arrêter son choix évite de reproduire une configuration conçue pour des serveurs d'une autre époque.

• « MyISAM est plus rapide. » L'affirmation valait pour des lectures seules sur un serveur à un seul utilisateur. Sous une charge mixte, le verrouillage au niveau de la ligne d'InnoDB et son buffer pool l'emportent nettement, surtout sur un site web qui reçoit des commentaires en continu.
• « InnoDB ne gère pas la recherche plein texte. » Faux depuis MySQL 5.6 : MATCH ... AGAINST fonctionne sur une indexation FULLTEXT InnoDB, avec sa propre liste de mots vides.
• « InnoDB prend trop de place. » Un fichier InnoDB atteint souvent un volume supérieur à son équivalent MyISAM, mais la compression de pages existe, et l'espace disque coûte moins cher qu'une réparation après panne.
• « MEMORY accélère n'importe quelle table. » Il devient intéressant pour une petite table de correspondance ; il fait perdre les données de toute autre table au premier redémarrage.
• « Changer de moteur casse l'application. » Le cas existe pour l'AUTO_INCREMENT par groupe ou un code qui suppose l'absence de transaction, mais une application web ordinaire ne voit aucune différence, sauf une meilleure tenue sous charge.

Pour le reste des réglages d'une base hébergée, sauvegarde, export ou accès à phpMyAdmin, la rubrique bases de données SQL regroupe les autres questions traitées sur le sujet.

Sources : manuel de référence de MySQL 8.4 (chapitres InnoDB, moteurs de stockage alternatifs, MEMORY, MyISAM et index FULLTEXT) ; base de connaissances de MariaDB, pages InnoDB et Aria ; consultés en octobre 2026.