WordPress exige un système de gestion de bases de données relationnelles compatible SQL. Deux moteurs dominent le marché : MySQL et MariaDB. Le choix entre les deux ne se résume plus à une question de préférence, car les versions supportées et leurs dates de fin de vie modifient concrètement la recommandation pour tout nouveau déploiement.
Divergences techniques entre MySQL et MariaDB pour WordPress
MySQL et MariaDB partagent un ancêtre commun et restent largement interchangeables pour WordPress. Cette compatibilité générale masque des différences de comportement réelles sur les fonctions JSON, les collations et certains modes SQL.
A découvrir également : Quelle est la première étape pour gérer son e-réputation ?
Un site qui fonctionne parfaitement sur MariaDB 10.11 en production peut générer des erreurs subtiles sur un environnement de développement local tournant sous MySQL 8.0, ou inversement. Nous recommandons de reproduire le moteur et la version exacte de production dans l’environnement de staging pour éviter ces écarts.
WordPress indique désormais comme versions recommandées MariaDB 10.11 ou supérieure, ou MySQL 8.0 ou supérieure. Les versions antérieures peuvent techniquement fonctionner, mais elles approchent ou ont déjà atteint leur fin de support, ce qui expose le site à des failles non corrigées.
Lire également : C'est quoi les données de site ?
Fin de support : un critère de choix concret
MySQL 8.0 a atteint sa fin de support le 30 avril 2026. Pour un projet lancé aujourd’hui, partir sur MySQL 8.4 LTS ou MariaDB 10.11+ reste la seule option raisonnable. Déployer une version en fin de vie revient à accumuler une dette technique dès le premier jour.
La plupart des hébergeurs mutualisés imposent le moteur et la version. Avant de souscrire une offre, vérifiez ce point dans le panneau d’administration ou auprès du support.
Performances de la base de données WordPress : où se situe le vrai goulot
Changer de moteur SQL ne suffit pas à résoudre un problème de lenteur. La base de données n’est pas toujours le principal facteur de ralentissement d’un site WordPress.
Trois éléments pèsent souvent davantage que le moteur lui-même :
- Le dimensionnement de PHP-FPM : un nombre insuffisant de workers PHP crée une file d’attente qui bloque les requêtes avant même qu’elles n’atteignent la base de données.
- La mémoire disponible pour le serveur SQL : des tables volumineuses sans assez de RAM forcent des lectures disque répétées, quel que soit le moteur utilisé.
- L’absence de cache objet (Redis, Memcached) : sans cette couche, chaque chargement de page déclenche des dizaines de requêtes SQL identiques au lieu de servir un résultat déjà calculé.
Nous observons régulièrement des sites migrés de MySQL vers MariaDB sans gain de vitesse perceptible, simplement parce que le bottleneck se trouvait côté PHP ou côté cache. Diagnostiquer avant de migrer évite une opération risquée pour un bénéfice nul.
Tables WordPress et maintenance SQL : ce que les plugins ne font pas
WordPress crée par défaut une douzaine de tables (wp_posts, wp_postmeta, wp_options, wp_users, etc.). Chaque extension installée peut ajouter ses propres tables, et la désinstallation ne les supprime pas toujours.
Les plugins d’optimisation de base de données nettoient les révisions, les transients expirés et les commentaires en corbeille. Ce nettoyage de surface est utile, mais il ne traite pas les problèmes structurels.
Requêtes lentes et index manquants
La table wp_postmeta est la plus sollicitée et la moins bien indexée par défaut. Sur un site avec plusieurs milliers de produits WooCommerce ou de champs ACF, l’ajout d’un index sur la colonne meta_value peut diviser le temps de certaines requêtes par un facteur significatif.
Aucun plugin grand public ne crée cet index automatiquement. L’opération se fait en une ligne SQL, mais elle nécessite de comprendre le schéma de la base et de tester sur un dump avant d’intervenir en production.
Autoload dans wp_options
Chaque ligne de la table wp_options marquée « autoload = yes » est chargée en mémoire à chaque requête PHP. Des extensions mal conçues stockent des données volumineuses avec autoload activé, ce qui gonfle la consommation mémoire sans raison.
Identifier et désactiver l’autoload sur les entrées non critiques (logs, caches expirés, configurations rarement lues) réduit la charge mémoire de chaque page. C’est un levier d’optimisation souvent plus efficace que de changer de moteur SQL.
Hébergement géré ou VPS : l’impact sur le choix du moteur SQL
Le type d’hébergement pèse souvent plus que le moteur choisi. Sur un hébergement mutualisé, vous n’avez aucun contrôle sur la version SQL, la configuration du buffer pool InnoDB ou les paramètres de connexion. Le moteur est imposé par l’hébergeur.
Sur un VPS ou un serveur dédié, le choix devient réel. MariaDB s’installe facilement sur les distributions Linux courantes et propose des réglages par défaut légèrement plus agressifs en termes de cache. MySQL 8.4 LTS offre de son côté un meilleur support natif des fonctions JSON et un optimiseur de requêtes remanié.
Pour un site WordPress classique (blog, vitrine, petit e-commerce), la différence de performance brute entre les deux moteurs reste marginale. Le choix se fait alors sur des critères pratiques :
- Quel moteur est proposé nativement par votre hébergeur ou votre image Docker
- Quelle version bénéficie du support le plus long (MySQL 8.4 LTS vs MariaDB 11.x)
- Quel moteur votre équipe maîtrise pour le monitoring et le tuning (slow query log, EXPLAIN, variables système)
Migrer d’un moteur à l’autre sur un WordPress existant se résume généralement à un dump/restore, mais les collations doivent être vérifiées table par table pour éviter des problèmes d’encodage sur les caractères spéciaux.
La meilleure base de données pour WordPress est celle qui tourne dans une version activement maintenue, sur un serveur correctement dimensionné, avec un cache objet en place. MariaDB 10.11+ et MySQL 8.4 LTS remplissent tous deux ce cahier des charges. Le reste dépend de votre infrastructure et de vos compétences d’administration.
