Convertir les tables WordPress de MyISAM à InnoDB avec WP-CLI

Sur un vieux site WordPress, il n’est pas rare de trouver encore des tables MyISAM. Le site fonctionne, certes. Mais sous charge, avec WooCommerce, des commentaires, beaucoup de métadonnées ou des écritures fréquentes, MyISAM peut vite devenir un vieux meuble qui grince dans une maison moderne.

InnoDB est aujourd’hui le moteur standard pour MySQL et MariaDB dans la majorité des installations WordPress. Il gère mieux la concurrence, les transactions, les verrous ligne par ligne et la fiabilité générale des écritures.

Dans ce guide, nous allons voir comment convertir les tables WordPress de MyISAM vers InnoDB avec WP-CLI, proprement, avec sauvegarde, diagnostic, script réutilisable, vérifications et plan de retour arrière.

MyISAM et InnoDB : pourquoi convertir ?

MyISAM est un ancien moteur de stockage MySQL. Il a longtemps été utilisé par défaut, notamment sur de vieilles installations. Cependant, il ne gère pas les transactions et repose sur un verrouillage beaucoup plus global des tables.

InnoDB apporte des avantages importants pour WordPress :

• meilleure gestion des écritures concurrentes ;
• verrouillage au niveau des lignes plutôt qu’au niveau de la table ;
• transactions ;
• meilleure récupération après crash ;
• meilleure base pour WooCommerce et les sites à fort trafic ;
• moteur par défaut sur les versions modernes de MySQL.

Pour un blog simple, la différence ne se voit pas toujours immédiatement. Pour une boutique WooCommerce, un site avec beaucoup de commentaires, un site membre ou une base volumineuse, InnoDB devient vite préférable.

Avant de convertir : sauvegarde obligatoire

La conversion avec ALTER TABLE ... ENGINE=InnoDB réécrit la table. Elle ne devrait pas supprimer les données, mais elle peut échouer si la table est énorme, corrompue, verrouillée ou si le serveur manque d’espace disque.

Commencez donc par exporter la base complète :

mkdir -p ~/backups

wp db export ~/backups/wordpress-before-myisam-innodb-$(date +%F-%H%M%S).sql --add-drop-table

Vérifiez ensuite que le fichier existe et qu’il n’est pas vide :

ls -lh ~/backups/wordpress-before-myisam-innodb-*.sqlLangage du code : JavaScript (javascript)

Sur un site critique, faites aussi une sauvegarde hébergeur ou un snapshot serveur. Une sauvegarde SQL, c’est bien. Une restauration testée, c’est mieux. Oui, c’est moins glamour qu’un plugin de cache avec des confettis, mais beaucoup plus utile quand ça pique.

Vérifier le préfixe de table WordPress

Ne partez jamais du principe que vos tables commencent par wp_. Beaucoup de sites utilisent un préfixe personnalisé.

wp db prefix

Cette commande permet de cibler les bonnes tables dans les requêtes suivantes. C’est particulièrement important sur les bases qui contiennent plusieurs installations WordPress.

Lister les tables MyISAM de WordPress

Pour afficher uniquement les tables MyISAM liées au préfixe WordPress courant :

wp db query "
SELECT
  TABLE_NAME,
  ENGINE,
  TABLE_ROWS,
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;
"Langage du code : PHP (php)

Si la requête ne retourne rien, vos tables WordPress ne sont pas en MyISAM. Vous pouvez vous arrêter là, ce qui est probablement le meilleur type d’intervention serveur : celle qui finit avant d’avoir commencé.

Pour afficher tous les moteurs utilisés par les tables WordPress :

wp db query "
SELECT
  ENGINE,
  COUNT(*) AS tables_count,
  ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
GROUP BY ENGINE
ORDER BY total_mb DESC;
"Langage du code : PHP (php)

Cette vue donne un bon résumé de l’état de la base.

Lister toutes les tables MyISAM de la base

Certains plugins créent des tables personnalisées. Elles ne commencent pas toujours par le préfixe WordPress, même si c’est préférable.

Pour afficher toutes les tables MyISAM de la base courante :

wp db query "
SELECT
  TABLE_NAME,
  ENGINE,
  TABLE_ROWS,
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND ENGINE = 'MyISAM'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;
"Langage du code : PHP (php)

Ne convertissez pas aveuglément une table inconnue. Identifiez d’abord le plugin ou l’application qui l’utilise. Certaines vieilles extensions peuvent dépendre de comportements spécifiques, même si c’est rarement une excellente nouvelle.

Vérifier que le serveur supporte InnoDB

Sur un serveur MySQL ou MariaDB moderne, InnoDB est normalement disponible. Vérifiez quand même :

wp db query "SHOW ENGINES;"Langage du code : JavaScript (javascript)

Vous devez voir InnoDB avec un support actif. Sur MySQL moderne, InnoDB est généralement le moteur par défaut.

Vous pouvez aussi vérifier le moteur par défaut :

wp db query "SHOW VARIABLES LIKE 'default_storage_engine';"Langage du code : JavaScript (javascript)

Convertir une seule table MyISAM en InnoDB

Pour convertir une table précise, utilisez :

wp db query "ALTER TABLE $(wp db prefix)posts ENGINE=InnoDB;"Langage du code : JavaScript (javascript)

Remplacez posts par la table concernée. Sur une table volumineuse, cette opération peut prendre du temps et verrouiller la table pendant la conversion.

Après conversion, vérifiez le moteur :

wp db query "
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = '$(wp db prefix)posts';
"Langage du code : PHP (php)

Cette méthode table par table est la plus prudente pour les sites importants.

Générer les commandes de conversion sans les exécuter

Avant de convertir, générez d’abord le SQL dans un fichier. Cela permet de relire les commandes et d’éviter une conversion trop large.

wp db query "
SELECT CONCAT('ALTER TABLE \`', TABLE_NAME, '\` ENGINE=InnoDB;') AS query
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) ASC;
" --skip-column-names > convert-myisam-to-innodb.sqlLangage du code : PHP (php)

Affichez ensuite le fichier :

cat convert-myisam-to-innodb.sqlLangage du code : CSS (css)

J’ai volontairement trié les tables de la plus petite à la plus grosse. Cela permet de convertir progressivement et de voir les éventuels problèmes avant d’attaquer les tables lourdes.

Convertir toutes les tables WordPress MyISAM vers InnoDB

Une fois le fichier relu, vous pouvez exécuter les conversions :

wp db query < convert-myisam-to-innodb.sqlLangage du code : CSS (css)

Puis supprimez le fichier SQL temporaire :

rm convert-myisam-to-innodb.sqlLangage du code : CSS (css)

Sur un gros site, lancez cette opération en période creuse. Évitez de convertir wp_posts, wp_postmeta, wp_options ou les tables WooCommerce pendant un pic de trafic. Le serveur n’a pas besoin d’un escape game SQL pendant les commandes clients.

Script Bash complet avec mode dry-run

Voici un script plus propre pour auditer et convertir les tables MyISAM. Par défaut, il ne fait qu’afficher les conversions prévues. Il faut passer --execute pour appliquer les changements.

#!/usr/bin/env bash

set -euo pipefail

MODE="${1:-dry-run}"
BACKUP_DIR="${BACKUP_DIR:-$HOME/backups}"
SQL_FILE="/tmp/convert-myisam-to-innodb-$(date +%F-%H%M%S).sql"

mkdir -p "${BACKUP_DIR}"

echo "Préfixe WordPress : $(wp db prefix)"
echo "Mode : ${MODE}"
echo

echo "Tables MyISAM détectées :"
wp db query "
SELECT
  TABLE_NAME,
  ENGINE,
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) ASC;
"

echo
echo "Génération du fichier SQL : ${SQL_FILE}"

wp db query "
SELECT CONCAT('ALTER TABLE \`', TABLE_NAME, '\` ENGINE=InnoDB;') AS query
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) ASC;
" --skip-column-names > "${SQL_FILE}"

if [[ ! -s "${SQL_FILE}" ]]; then
  echo "Aucune table MyISAM WordPress à convertir."
  rm -f "${SQL_FILE}"
  exit 0
fi

echo
echo "Commandes prévues :"
cat "${SQL_FILE}"

if [[ "${MODE}" != "--execute" ]]; then
  echo
  echo "Dry-run uniquement. Relancez avec --execute pour convertir."
  exit 0
fi

echo
echo "Export de sauvegarde..."
wp db export "${BACKUP_DIR}/before-myisam-innodb-$(date +%F-%H%M%S).sql" --add-drop-table

echo
echo "Conversion en cours..."
wp db query < "${SQL_FILE}"

echo
echo "Vérification après conversion :"
wp db query "
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM';
"

rm -f "${SQL_FILE}"

echo
echo "Terminé."Langage du code : PHP (php)

Créez le fichier :

nano convert-myisam-to-innodb.shLangage du code : CSS (css)

Rendez-le exécutable :

chmod +x convert-myisam-to-innodb.shLangage du code : CSS (css)

Lancez d’abord le mode dry-run :

./convert-myisam-to-innodb.sh

Puis exécutez réellement la conversion :

./convert-myisam-to-innodb.sh --execute

Vérifier qu’il ne reste plus de tables MyISAM

Après conversion, relancez l’audit :

wp db query "
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
  AND ENGINE = 'MyISAM';
"Langage du code : PHP (php)

Si aucune ligne ne remonte, vos tables WordPress préfixées ne sont plus en MyISAM.

Vous pouvez aussi afficher un résumé complet :

wp db query "
SELECT
  ENGINE,
  COUNT(*) AS tables_count,
  ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE CONCAT('$(wp db prefix)', '%')
GROUP BY ENGINE
ORDER BY total_mb DESC;
"Langage du code : PHP (php)

Optimiser et vérifier la base après conversion

Après la conversion, vérifiez l’état de la base :

wp db check

Puis lancez une optimisation si nécessaire :

wp db optimize

Videz ensuite le cache objet WordPress :

wp cache flush

Si vous utilisez Redis, un cache page, un cache hébergeur ou Cloudflare, purgez aussi ces couches selon votre stack.

Points d’attention pour WooCommerce

WooCommerce écrit beaucoup en base : commandes, sessions, paniers, actions planifiées, métadonnées, webhooks et logs selon les extensions. InnoDB est généralement préférable pour ces usages.

Avant conversion sur une boutique :

• travaillez sur staging si possible ;
• évitez les heures de commande ;
• surveillez les logs PHP et MySQL ;
• vérifiez le checkout après conversion ;
• contrôlez les actions planifiées WooCommerce ;
• testez les paiements, emails et webhooks critiques.

Après conversion, vérifiez notamment :

wp cron event list | head
wp action-scheduler action list --status=pending --per-page=20Langage du code : PHP (php)

La commande Action Scheduler dépend de WooCommerce ou du package Action Scheduler. Si elle n’existe pas, ce n’est pas forcément un problème.

Gérer les erreurs courantes

La conversion est lente

C’est normal sur une grosse table. MySQL doit reconstruire la table. Lancez l’opération en période creuse, table par table, et surveillez la charge serveur.

La table est verrouillée trop longtemps

Sur une grosse table active, la conversion peut bloquer des écritures. Dans ce cas, planifiez une fenêtre de maintenance ou migrez sur staging, puis basculez proprement.

Le serveur manque d’espace disque

La conversion peut nécessiter de l’espace temporaire. Vérifiez l’espace disponible avant de lancer l’opération :

df -h
du -sh /var/lib/mysqlLangage du code : JavaScript (javascript)

Adaptez le chemin MySQL si votre datadir est ailleurs.

Une table est corrompue

Avant conversion, vérifiez la table :

wp db query "CHECK TABLE $(wp db prefix)posts;"Langage du code : JavaScript (javascript)

Pour une table MyISAM corrompue, une réparation peut être nécessaire :

wp db query "REPAIR TABLE $(wp db prefix)posts;"Langage du code : JavaScript (javascript)

Ne réparez pas tout en vrac. Identifiez la table concernée, sauvegardez, puis intervenez.

Plan de rollback

Si quelque chose se passe mal, restaurez la sauvegarde SQL réalisée avant conversion :

wp db import ~/backups/wordpress-before-myisam-innodb-YYYY-MM-DD-HHMMSS.sqlLangage du code : JavaScript (javascript)

Puis videz le cache :

wp cache flush

Sur un site important, restaurez plutôt un snapshot complet si vous en avez un. C’est souvent plus rapide et plus sûr qu’un import SQL sur une grosse base.

Faut-il convertir toutes les tables MyISAM ?

Pour les tables WordPress classiques, oui, dans la grande majorité des cas. Pour les tables personnalisées, vérifiez d’abord leur usage.

Une vieille table MyISAM appartenant à un plugin supprimé depuis des années n’a peut-être pas besoin d’être convertie. Elle doit peut-être être archivée ou supprimée après audit.

Pour identifier les restes de plugins dans la base, vous pouvez compléter ce travail avec ce guide pour identifier les options de base de données liées à un plugin WordPress.

Pour aller plus loin sur l’optimisation de base WordPress

Si vous convertissez vos tables vers InnoDB, ces guides complètent bien l’audit, le nettoyage et la maintenance de votre base WordPress.

• Identifier les options de base de données liées à un plugin WordPress
• Désinstaller WPML proprement et nettoyer la base WordPress avec WP-CLI
• Nettoyer complètement la base WordPress après la désinstallation d’Elementor
• Réparer wp_options sans clé primaire ni unique key dans WordPress
• Migrer WordPress avec WP-CLI vers un nouveau serveur

FAQ

Est-ce risqué de convertir MyISAM en InnoDB ?

La conversion est généralement sûre, mais elle réécrit les tables. Sauvegardez toujours la base avant de commencer et travaillez sur staging pour les sites critiques.

La conversion supprime-t-elle les données ?

Non, pas en fonctionnement normal. La commande ALTER TABLE ... ENGINE=InnoDB convertit le moteur de stockage. Cependant, une erreur serveur, une corruption ou un manque d’espace disque peut casser l’opération.

Faut-il convertir wp_posts et wp_postmeta ?

Oui, dans la plupart des cas. Ce sont des tables centrales de WordPress, souvent très sollicitées. InnoDB est généralement plus adapté, surtout sur les sites actifs.

Puis-je convertir en production ?

Oui, mais seulement avec une sauvegarde récente, en période creuse, et idéalement table par table. Pour WooCommerce ou un gros site, préférez une fenêtre de maintenance.

Pourquoi certaines tables restent en MyISAM ?

Elles peuvent appartenir à un vieux plugin, à une application externe ou à un ancien module. Identifiez leur origine avant de les convertir ou de les supprimer.

InnoDB améliore-t-il toujours les performances ?

Pas automatiquement sur chaque requête. Cependant, pour WordPress moderne, les écritures concurrentes, WooCommerce et la fiabilité générale, InnoDB est le meilleur choix dans la majorité des cas.

Conclusion

Convertir les tables WordPress de MyISAM à InnoDB est une opération simple, mais elle mérite une méthode propre. Commencez par auditer les moteurs utilisés, sauvegardez la base, générez les requêtes, relisez-les, puis convertissez progressivement.

Sur les sites WordPress actuels, InnoDB offre une meilleure base pour la fiabilité, les écritures concurrentes et les charges applicatives modernes. C’est particulièrement vrai pour WooCommerce, les sites éditoriaux volumineux et les installations anciennes qui ont beaucoup vécu.

Comme souvent en administration système, la commande est courte. La vraie valeur se trouve dans le diagnostic avant, la sauvegarde avant, et les vérifications après. Le terminal adore les gens méthodiques.

Sources

• MySQL 8.4 Reference Manual : Converting Tables from MyISAM to InnoDB
• MySQL 8.4 Reference Manual : Setting the Storage Engine
• MySQL 8.4 Reference Manual : Storage Engines
• WP-CLI : wp db commands

Report a typo