Deux tables d’une même base peuvent, en coulisses, fonctionner selon des règles totalement différentes : l’une capable d’annuler une opération en cas d’erreur, l’autre non. Ce comportement dépend d’un réglage propre à chaque table, souvent ignoré tant que tout se passe bien.
InnoDB a remplacé MyISAM par défaut
Longtemps, les tables WordPress étaient créées en MyISAM, plus rapide en lecture pure mais dépourvu de transactions et de contraintes de clé étrangère. Depuis WordPress 5.5, l’installateur crée désormais les tables en InnoDB par défaut, qui apporte les transactions, un meilleur comportement en concurrence d’écriture, et la recherche plein texte depuis MySQL 5.6. Une installation ancienne migrée au fil des versions peut cependant conserver des tables encore en MyISAM.
Exemple : vérifier et convertir
SHOW TABLE STATUS WHERE Engine = 'MyISAM';
ALTER TABLE wp_posts ENGINE = InnoDB;
Bon à savoir
- La commande WP-CLI
wp db query "SHOW TABLE STATUS"permet d’auditer rapidement le moteur de chaque table sans ouvrir phpMyAdmin. - Convertir une table volumineuse verrouille son accès en écriture pendant l’opération : à programmer en dehors des pics de trafic.
- La recherche plein texte MySQL (
MATCH() AGAINST()) nécessite un index spécifique compatible InnoDB uniquement depuis les versions récentes du moteur, à ne pas confondre avec la recherche standard de WordPress fondée surLIKE. - Une table MyISAM verrouille l’intégralité de la table à chaque écriture, tandis qu’InnoDB ne verrouille que les lignes concernées : sur un site à fort trafic de commentaires ou de commandes, cette différence peut expliquer des ralentissements inattendus lors de pics simultanés.