Migrer une base WordPress de MyISAM vers InnoDB sans perdre une seule donnée

Le site datait de l’époque WordPress 3.x, repris tel quel par plusieurs prestataires successifs sans qu’aucun n’ait jamais touché au moteur de stockage de la base. Un SHOW TABLE STATUS rapide a confirmé le soupçon : toutes les tables tournaient encore en MyISAM, le moteur par défaut de MySQL avant que InnoDB ne devienne le standard à partir de MySQL 5.5, sorti en 2010. Onze ans plus tard, ce site fragile méritait une mise à niveau avant qu’un incident ne la rende obligatoire dans l’urgence.

MyISAM verrouille la table entière à chaque opération d’écriture, ce qui devient un goulot d’étranglement dès qu’un site reçoit des écritures concurrentes (commentaires, mises à jour de compteurs de vues, sessions WooCommerce). InnoDB, à l’inverse, verrouille au niveau de la ligne concernée et gère les transactions, avec une récupération après crash bien plus robuste. Voici la méthode suivie pour cette conversion, table par table, sans rien perdre au passage.

Étape 1 : sauvegarder avant tout, et vérifier l’état de départ

Aucune conversion de moteur ne se lance sans une sauvegarde complète et vérifiée au préalable. Un export SQL classique suffit, mais doit être testé par une restauration sur un environnement séparé avant de continuer :

wp db export backup-avant-innodb.sql
mysql -u root -p test_restauration < backup-avant-innodb.sql

Une fois cette sécurité posée, l'inventaire des tables et de leur moteur actuel permet de savoir précisément ce qui doit être converti :

SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'nom_de_la_base'
ORDER BY table_name;

Étape 2 : convertir table par table, pas en un seul bloc

Il est tentant de vouloir tout convertir en une seule commande. C'est une mauvaise idée sur un site en production : convertir table par table permet d'isoler immédiatement la table fautive en cas d'anomalie, et de limiter la durée de verrouillage à chaque opération.

ALTER TABLE wp_posts ENGINE=InnoDB;
ALTER TABLE wp_postmeta ENGINE=InnoDB;
ALTER TABLE wp_comments ENGINE=InnoDB;
ALTER TABLE wp_commentmeta ENGINE=InnoDB;
ALTER TABLE wp_options ENGINE=InnoDB;
ALTER TABLE wp_users ENGINE=InnoDB;
ALTER TABLE wp_usermeta ENGINE=InnoDB;
ALTER TABLE wp_terms ENGINE=InnoDB;
ALTER TABLE wp_term_taxonomy ENGINE=InnoDB;
ALTER TABLE wp_term_relationships ENGINE=InnoDB;
ALTER TABLE wp_links ENGINE=InnoDB;

Sur une table volumineuse, cette opération réécrit physiquement toutes les données dans le nouveau format de stockage : sur wp_posts ou wp_postmeta d'un site ancien avec plusieurs dizaines de milliers d'articles, l'opération peut prendre plusieurs minutes et doit idéalement être planifiée en dehors des heures de forte fréquentation.

Le piège des index FULLTEXT

Un point mérite une attention particulière avant de lancer la conversion : certains sites, souvent via une extension de recherche ancienne, ajoutent des index FULLTEXT sur wp_posts pour accélérer les recherches en texte intégral. Historiquement, seul MyISAM supportait ce type d'index ; InnoDB ne l'a pris en charge qu'à partir de MySQL 5.6, sorti en 2013. Sur une base restée en MyISAM depuis 2010, cette compatibilité doit être vérifiée avant la conversion :

SHOW INDEX FROM wp_posts WHERE Index_type = 'FULLTEXT';

Si un index FULLTEXT est présent et que le serveur MySQL est suffisamment récent (5.6 ou plus, ou toute version actuelle de MariaDB), la conversion se déroule sans encombre et l'index est recréé automatiquement dans le nouveau moteur. Sur un serveur trop ancien, il faudrait d'abord mettre à niveau le serveur de base de données lui-même, une étape distincte qui ne relève plus du seul moteur de stockage.

Vérifier après conversion, sans se contenter du silence

Une fois la conversion terminée, plusieurs contrôles doivent confirmer que rien n'a été altéré :

• Reconfirmer que toutes les tables affichent désormais InnoDB via la requête information_schema.tables utilisée en début de procédure.
• Parcourir le site en conditions réelles : publication d'un brouillon, ajout d'un commentaire, connexion utilisateur, pour vérifier que les écritures fonctionnent normalement.
• Vérifier le comportement de la recherche native si un index FULLTEXT était en jeu, en testant plusieurs requêtes de recherche représentatives du contenu du site.
• Contrôler les logs d'erreur MySQL (/var/log/mysql/error.log ou équivalent) sur les heures suivant la conversion, à la recherche d'éventuels avertissements liés au nouveau moteur.

Une conversion de moteur qui se termine sans message d'erreur n'est pas encore une conversion validée : c'est seulement une conversion qui n'a rien cassé de visible immédiatement. Le vrai test, c'est l'usage normal du site dans les heures qui suivent.

En résumé

Convertir une base WordPress héritée de MyISAM vers InnoDB n'a rien d'exceptionnel techniquement, mais mérite une méthode rigoureuse : sauvegarde vérifiée, conversion table par table, attention particulière aux index FULLTEXT sur wp_posts, et vérification fonctionnelle complète après coup. Ce chantier ne s'attaque pas encore à l'optimisation des index une fois le nouveau moteur en place, un sujet à part entière qui suppose une base déjà stabilisée en InnoDB.