MySQL & MariaDB pour WordPress : tuning complet, performance et bonnes pratiques (2025)

1. Le rôle de MySQL/MariaDB dans WordPress

WordPress est historiquement couplé à MySQL, et de plus en plus souvent à MariaDB, un fork maintenu et très populaire. Tout ce qui concerne le contenu et la configuration (ou presque) transite par la base de données. Chaque chargement de page génère plusieurs requêtes SQL : récupération d’options, des posts, des menus, des widgets, des métadonnées, etc.

Une base sous-dimensionnée ou mal configurée se manifeste par :

• un Time To First Byte (TTFB) élevé,
• des pages qui restent bloquées sur “Chargement…”,
• un back-office extrêmement lent,
• des erreurs 500 ou 504 sous charge,
• un CPU MySQL qui explose lors de certains pics.

L’objectif de ce tuning est de limiter au maximum ces phénomènes, tout en gardant une configuration stable et maintenable dans le temps.

2. Choix du moteur de stockage : InnoDB obligatoire

Il existe plusieurs moteurs de stockage dans MySQL/MariaDB (MyISAM, InnoDB, MEMORY, etc.). Pour WordPress, le choix est aujourd’hui très clair : InnoDB doit être utilisé partout.

Les avantages d’InnoDB par rapport à MyISAM :

• Support des transactions.
• Verrouillage ligne par ligne (au lieu de verrous de table complets).
• Meilleure résistance aux crashs.
• Meilleure performance générale sur les workloads WordPress modernes.

Si vous avez encore des tables en MyISAM (sur d’anciens sites migrés par exemple), il est fortement recommandé de les convertir en InnoDB :

ALTER TABLE wp_posts ENGINE=InnoDB;
ALTER TABLE wp_postmeta ENGINE=InnoDB;
ALTER TABLE wp_options ENGINE=InnoDB;

Commencez par les tables les plus utilisées (wp_posts, wp_postmeta, wp_options, wp_usermeta, etc.).

3. Régler le buffer pool InnoDB

Le buffer pool InnoDB est l’un des paramètres les plus importants de MySQL/MariaDB. Il s’agit de la zone mémoire où InnoDB stocke les données les plus fréquemment accédées (pages de données, index).

Si le buffer pool est trop petit :

• La base de données doit constamment relire les données sur le disque.
• Les temps de réponse augmentent.
• Le disque (même NVMe) devient un goulot d’étranglement.

Si le buffer pool est trop grand (et dépasse la RAM disponible), le système commencera à swapper, ce qui est encore pire.

3.1. Règle générale pour innodb_buffer_pool_size

Sur un serveur où MySQL/MariaDB est le principal consommateur de RAM, une recommandation courante est :

innodb_buffer_pool_size ≈ 50–60 % de la RAM totale

Si le serveur héberge également d’autres services gourmands (PHP-FPM, Redis, etc.), vous pouvez ajuster :

• VPS 8 Go RAM : buffer pool de 2–3 Go.
• VPS 16 Go RAM : buffer pool de 6–8 Go.
• Serveur dédié 32 Go et + : buffer pool de 16–20 Go selon usage.

Exemple de configuration :

innodb_buffer_pool_size = 3G
innodb_buffer_pool_instances = 2

3.2. Vérifier l’efficacité du buffer pool

Vous pouvez vérifier la taille du buffer pool et son activité via :

SHOW ENGINE INNODB STATUS\G;

Ou via des outils comme mysqltuner, qui donnent des recommandations basées sur l’usage réel. L’objectif est que la plupart des lectures soient servies depuis le buffer pool et non depuis le disque.

4. Paramètres MySQL/MariaDB essentiels pour WordPress

En plus du buffer pool, d’autres paramètres ont un impact direct sur la stabilité et les performances.

4.1. innodb_log_file_size & innodb_flush_log_at_trx_commit

innodb_log_file_size définit la taille des fichiers de log InnoDB. Un fichier trop petit peut entraîner des flushs trop fréquents, un fichier trop grand peut compliquer certaines opérations (recovery). Pour la plupart des serveurs WordPress :

innodb_log_file_size = 512M est un bon compromis.

innodb_flush_log_at_trx_commit contrôle la durabilité des transactions :

• 1 : le plus sûr, mais le plus lent.
• 2 : bon compromis pour la plupart des sites.
• 0 : plus rapide, mais plus risqué en cas de crash.

Pour WordPress, un réglage courant est :

innodb_flush_log_at_trx_commit = 2

4.2. max_connections et thread cache

max_connections définit le nombre maximum de connexions simultanées à la base. Le réflexe courant est de “l’augmenter” pour ne plus voir d’erreurs, mais chaque connexion consomme de la RAM.

Sur un serveur WordPress, des valeurs raisonnables sont :

• 100 à 200 connexions max pour un parc de sites moyen.
• Éviter les 500–1000 connexions si la RAM n’est pas très élevée.

Coupler cela à un bon tuning PHP-FPM (pour éviter trop de processus PHP simultanés) permet de garder un équilibre.

4.3. query_cache_size & query_cache_type (MySQL < 8)

Le “query cache” historique de MySQL est obsolète et retiré dans MySQL 8. Si vous êtes encore sur une version plus ancienne :

query_cache_type = 0
query_cache_size = 0

Sur MariaDB, le query cache existe encore, mais il est souvent préférable de le désactiver pour des sites WordPress dynamiques et de préférer un cache objet comme Redis.

5. Slow query log : identifier les requêtes lentes

Avant d’ajuster des paramètres à l’aveugle, il est souvent plus utile de savoir quelles requêtes sont réellement lentes. C’est le rôle du slow query log.

5.1. Activer le slow query log

Dans votre fichier de configuration MySQL/MariaDB :

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 0

Cela enregistrera les requêtes qui prennent plus d’une seconde. Vous pouvez ajuster long_query_time selon votre tolérance.

5.2. Analyser les requêtes lentes

Vous pouvez analyser ce log avec des outils comme mysqldumpslow ou pt-query-digest (Percona Toolkit) pour identifier :

• les requêtes les plus fréquentes,
• les requêtes les plus lentes,
• les requêtes qui scannent beaucoup de lignes.

Les coupables sont souvent :

• des requêtes générées par certains plugins (statistiques, builder, recherche avancée),
• des requêtes sur des tables gonflées (logs, sessions, options),
• des requêtes sans index adéquat.

6. Organisation des bases pour plusieurs sites WordPress

Si vous hébergez plusieurs WordPress sur le même serveur, la manière dont vous organisez vos bases de données a un gros impact sur la maintenance et la sécurité.

6.1. Une base par site plutôt qu’une base unique

Il est tentant de mettre plusieurs sites dans une seule base avec des préfixes différents (wp_site1_, wp_site2_…), mais cela complique :

• les migrations et restaurations,
• la gestion des droits utilisateurs,
• la lisibilité globale du schéma.

Pour un environnement professionnel, il est recommandé de créer :

• Une base par site (ex. site1_wp, site2_wp).
• Un utilisateur par site, avec des droits limités à sa base.

Exemple :

CREATE DATABASE site1_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site1_user'@'localhost' IDENTIFIED BY 'motdepassefort';
GRANT ALL PRIVILEGES ON site1_wp.* TO 'site1_user'@'localhost';
FLUSH PRIVILEGES;

6.2. Multi-site WordPress vs multi-sites “séparés”

WordPress Multisite (réseau) utilise un schéma de base de données différent (tables avec suffixes _blogid). C’est adapté dans certains cas (réseau cohérent, même code, mêmes plugins), mais plus complexe à gérer :

• Les migrations sont plus délicates.
• Certains plugins ne sont pas toujours multisite-friendly.
• La base peut devenir très volumineuse.

Pour beaucoup d’agences et de freelances, il reste plus simple de gérer plusieurs installations WordPress “séparées”, chacune avec sa base dédiée.

7. Indexation, schéma et hygiène des données

Une fois la configuration serveur bien réglée, la structure même des tables et les données qu’elles contiennent jouent un rôle important.

7.1. Indexes sur les colonnes fréquemment filtrées

WordPress crée déjà les index nécessaires sur ses tables de base. Le problème vient souvent de certains plugins qui ajoutent des tables ou des colonnes sans index adéquats.

Dans les rapports de slow query log, si vous voyez souvent des requêtes sur une table non indexée, vous pouvez envisager d’ajouter un index avec précaution (en environnement de test d’abord).

7.2. Nettoyage des données inutiles

Au fil du temps, certaines tables WordPress peuvent se remplir de données peu utiles :

• Révisions d’articles en trop grand nombre.
• Commentaires spam non purgés.
• Logs obsolètes de certains plugins.
• Transients expirés qui n’ont pas été nettoyés.

Des plugins comme WP-Optimize ou des scripts SQL ciblés peuvent aider à garder les tables propres. Toujours faire une sauvegarde avant tout nettoyage massif.

7.3. Charset & collation recommandés

En 2025, il est conseillé d’utiliser :

• utf8mb4 comme charset.
• utf8mb4_unicode_ci ou utf8mb4_unicode_520_ci comme collation.

Cela garantit une bonne gestion des emojis, des caractères internationaux et des tri corrects sur de nombreux alphabets.

8. Maintenance régulière et sauvegardes

Une base de données WordPress performante n’est pas seulement une histoire de tuning initial. C’est aussi une routine de maintenance régulière.

8.1. Maintenance SQL

• Vérifier les tables : CHECK TABLE.
• Réparer si nécessaire : REPAIR TABLE (sur MyISAM, à éviter sur InnoDB).
• Optimiser les tables fragmentées : OPTIMIZE TABLE.

Sur les gros sites, il vaut mieux programmer ces opérations pendant les heures creuses.

8.2. Sauvegardes régulières

Enfin, une bonne configuration MySQL/MariaDB doit s’accompagner d’un plan de sauvegarde solide :

• Sauvegardes automatiques quotidiennes de toutes les bases.
• Stockage sur un support externe (S3, autre serveur, etc.).
• Rétention de plusieurs versions (30 jours, voire plus selon les besoins).
• Tests réguliers de restauration.

Des outils comme WPvivid (côté WordPress) ou des scripts mysqldump côté serveur peuvent être combinés pour une stratégie de sauvegarde robuste.

FAQ – MySQL/MariaDB & WordPress

Quelle est la meilleure version : MySQL ou MariaDB pour WordPress ?

Les deux fonctionnent très bien avec WordPress. MariaDB a souvent une légère avance en termes de fonctionnalités et de performance sur certains cas, mais MySQL 8 reste une valeur sûre. L’important est d’utiliser une version maintenue et à jour, plutôt que de rester sur un MySQL 5.5/5.6 obsolète.

Dois-je activer le query cache pour accélérer WordPress ?

Non. Sur MySQL 5.7+ et MariaDB récents, le query cache est soit deprecated, soit contre-productif pour des sites dynamiques comme WordPress. Préférez un object cache (Redis) et un bon tuning InnoDB.

Mon slow query log est plein, que faire ?

C’est une bonne nouvelle : vous avez maintenant une liste des requêtes les plus lentes. Utilisez mysqldumpslow ou pt-query-digest pour les regrouper et identifier les queries problématiques. La solution peut être de :

• ajouter un index approprié,
• désactiver ou remplacer un plugin trop gourmand,
• nettoyer des tables trop volumineuses,
• augmenter légèrement certaines ressources (buffer pool, etc.).

Combien de bases puis-je avoir sur un même serveur ?

Techniquement, MySQL/MariaDB supporte un grand nombre de bases. Le facteur limitant n’est pas le nombre de bases, mais la charge globale (nombre de requêtes, taille des données, ressources serveur). Il n’est pas rare d’avoir 20–50 sites WordPress sur un VPS bien tuné, à condition d’avoir suffisamment de CPU/RAM et une bonne organisation.

Est-ce que l’optimisation SQL suffit à rendre mon WordPress rapide ?

Non, la base de données est une brique importante, mais elle n’est qu’une partie de l’architecture. Pour un WordPress vraiment rapide, il faut combiner : un serveur web bien configuré, PHP-FPM optimisé, MySQL/MariaDB tuné, cache (page + objet), CDN et un thème/plugins raisonnablement conçus.

Conclusion : une base saine pour un WordPress rapide

Optimiser MySQL ou MariaDB pour WordPress, c’est donner un socle solide à toute votre infrastructure web. Un bon tuning InnoDB, un buffer pool adapté, des paramètres raisonnables pour les connexions, un slow query log exploité et une organisation claire des bases permettent d’éviter une grande partie des problèmes de performance qui se manifestent un jour ou l’autre.

Combinée aux optimisations serveur (Apache/Nginx), à un PHP-FPM correctement dimensionné et à un cache efficace, une base bien configurée fait la différence entre un WordPress “qui passe” et un WordPress qui reste rapide et stable sur la durée, même avec plusieurs sites et des pics de trafic.

Ce guide s’inscrit dans le cluster “Serveur & Performance WordPress” du Mag Web. En le croisant avec les articles sur l’architecture serveur, PHP-FPM, Redis, Cloudflare et la sécurité, vous pouvez construire une plateforme d’hébergement WordPress professionnelle, adaptée aux besoins des TPE/PME comme des freelances et agences.