Nettoyer une base de données WordPress gonflée : méthode sûre

Si ton site commence à ramer, que l’admin met du temps à charger, ou que tes sauvegardes deviennent anormalement lourdes, il y a de fortes chances que la base de données WordPress soit gonflée. La bonne nouvelle ? Tu peux l’alléger de façon structurée et sans risque. Dans ce guide, on va nettoyer ce qui pèse le plus (les révisions d’articles, les transients, et les tables orphelines), puis optimiser MySQL (index et statistiques) avec WP-CLI et quelques requêtes SQL ciblées. L’objectif : une optimisation BDD mesurable, des pages qui se chargent plus vite et une maintenance qui dure dans le temps.

Tu vas découvrir une méthode pro : préparation et sauvegardes, audit précis, nettoyage par étapes, optimisation, puis vérifications. Sur la partie technique, rien d’insurmontable : quelques commandes WP-CLI, des requêtes standard et des bonnes pratiques pour ne rien casser en prod. Et si tu préfères déléguer, l’équipe WP Builders peut s’en charger, avec sauvegarde préalable, plan de rollback et reporting clair de l’avant/après.

Prêt·e ? On sécurise d’abord, puis on nettoie ce qui gonfle : révisions multiples, brouillons auto, transients expirés, options autoload trop lourdes et tables laissées par d’anciens plugins. Ensuite, on optimise MySQL : analyse des index, ANALYZE TABLE, OPTIMIZE TABLE et création d’index utiles (notamment sur wp_postmeta). Cette approche, éprouvée sur des sites de toutes tailles, te permettra d’obtenir un résultat rapide et durable.

Pourquoi ta base de données WordPress gonfle (et comment le prouver)

Révisions d’articles et autosaves

Par défaut, WordPress conserve l’historique de chaque contenu. Utile pour revenir en arrière, mais coûteux lorsque des articles sont souvent édités. Les révisions s’accumulent et remplissent wp_posts. Les brouillons automatiques et révisions obsolètes finissent par ralentir les requêtes.

Transients expirés et options autoload

Les transients stockent des données mises en cache dans la base. Ils expirent… mais restent parfois présents. Les options avec autoload = yes sont chargées à chaque requête : si elles gonflent, c’est toute la page qui en pâtit.

Tables orphelines après désactivation de plugins

Beaucoup d’extensions créent leurs propres tables et ne les suppriment pas à la désinstallation. Résultat : une base plus volumineuse, des sauvegardes plus lentes et un risque de collisions de noms dans le futur.

Logs, sessions, paniers et autres données temporaires

Sur un e-commerce, les sessions, paniers abandonnés et logs d’API peuvent grossir très vite. Ces données doivent être purgées régulièrement.

Sécuriser l’opération : sauvegarde, staging et checklist

Avant tout nettoyage, on sécurise. C’est la partie la plus importante.

Sauvegarde complète et test de restauration

Fais une sauvegarde SQL + fichiers, et vérifie que tu peux la restaurer. En WP-CLI :

# Export de la base avec horodatagewp db export wpb-before-clean-$(date +%F).sql --add-drop-table# Optionnel : compresser l’exportgzip wpb-before-clean-$(date +%F).sql

Si ton hébergeur propose des snapshots ou des backups automatiques, crée un point de restauration dédié et note l’heure exacte.

Staging ou maintenance courte

L’idéal est de cloner le site en staging, d’exécuter l’opération, puis de reproduire en prod. Si ce n’est pas possible, active un mode maintenance court pendant le nettoyage pour éviter des écritures concurrentes.

Check-list rapide

• Accès SSH et WP-CLI fonctionnels.
• Version PHP/MySQL à jour.
• Préfixe de table noté (ex : wp_ ou personnalisé).
• Temps calme (pas de pic de trafic, pas de campagne en cours).

Auditer la base : mesurer avant d’agir (WP-CLI + SQL)

On commence par mesurer la taille et repérer ce qui pèse.

# Taille globale de la base et par tablewp db size --human-readablewp db size --tables --human-readable# Top tables par volume (SQL)SELECT table_name,       ROUND((data_length+index_length)/1024/1024,2) AS size_mbFROM information_schema.tablesWHERE table_schema = DATABASE()ORDER BY size_mb DESC;

Repère les tables qui grossissent : wp_posts (révisions), wp_postmeta, wp_options (autoload/transients), tables d’extension (Woo, SEO, logs, etc.).

Compter les révisions et brouillons auto

SELECT COUNT(*) AS nb_revisionsFROM wp_postsWHERE post_type = 'revision';SELECT COUNT(*) AS nb_autosavesFROM wp_postsWHERE post_status = 'auto-draft';

(Adapte wp_ à ton préfixe.)

Lister les transients expirés et options lourdes

# WP-CLI : transients expiréswp transient list --fields=name,expiration --format=table# Options autoload volumineuses (SQL)SELECT option_name, LENGTH(option_value) AS bytesFROM wp_optionsWHERE autoload = 'yes'ORDER BY bytes DESCLIMIT 20;

Pour plus de détails sur les commandes, consulte la doc WP-CLI.

Nettoyer en toute sécurité : révisions, transients, commentaires, tables

Nettoyons progressivement, en vérifiant après chaque étape.

Purger les révisions d’articles

Si tu en as des dizaines de milliers, commence par une purge. Avec WP-CLI :

# Supprimer toutes les révisionswp post delete $(wp post list --post_type='revision' --format=ids) --force

En SQL (plus rapide sur de gros volumes) :

DELETE FROM wp_posts WHERE post_type = 'revision';

Ensuite, limite les futures révisions dans wp-config.php :

define('WP_POST_REVISIONS', 5); // garde 5 révisions max

Purger les transients expirés (puis tous si nécessaire)

# Supprimer uniquement les transients expirés (recommandé)wp transient delete --expired# En dernier recours, supprimer tous les transientswp transient delete --all

En SQL, cible les clés de transients dans wp_options :

DELETE FROM wp_optionsWHERE option_name LIKE '\_transient\_%'  AND option_name NOT LIKE '\_transient\_timeout\_%';

Commentaires indésirables et corbeille

# Corbeille des commentairesDELETE FROM wp_comments WHERE comment_approved = 'spam' OR comment_approved = 'trash';# Corbeille des postsDELETE FROM wp_posts WHERE post_status = 'trash';

Identifier et traiter les tables orphelines

Compare la liste des tables à tes extensions actives. Exemple : des wp_woocommerce_* sans WooCommerce actif sont suspectes. Commence par renommer une table au lieu de la supprimer pour tester :

RENAME TABLE wp_old_plugin_table TO wp_old_plugin_table_bak;

Si tout fonctionne après quelques jours, tu peux supprimer :

DROP TABLE wp_old_plugin_table_bak;

Astuce : exporte la table avant suppression pour te garder un filet de sécurité :

wp db export table-wp_old_plugin_table.sql --tables=wp_old_plugin_table

Confie le nettoyage de ta BDD à des pros

Intervention sécurisée, sauvegarde incluse et optimisation mesurée. Démarrage en moins de 2 heures.

Voir nos offres de maintenance

Optimiser MySQL après nettoyage : ANALYZE, OPTIMIZE et index utiles

Une fois la purge effectuée, place à l’optimisation structurelle pour tirer le meilleur de MySQL.

Mettre à jour les statistiques de l’optimiseur

ANALYZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

Cela aide l’optimiseur à choisir de meilleurs plans d’exécution.

Défragmenter et récupérer de l’espace

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

Sur InnoDB, OPTIMIZE reconstruit la table et peut réduire la fragmentation. Pour bien comprendre les impacts et alternatives, consulte le guide d’optimisation MySQL.

Indexer ce qui compte vraiment (wp_postmeta et wp_options)

wp_postmeta est souvent le goulot d’étranglement. Deux index généralement payants :

-- Index sur meta_key (utile pour les requêtes sur un meta précis)ALTER TABLE wp_postmeta  ADD INDEX meta_key (meta_key(191));-- Index composite post_id + meta_key pour accélérer les jointuresALTER TABLE wp_postmeta  ADD INDEX post_id_meta_key (post_id, meta_key(191));

Sur wp_options, si tu as beaucoup d’options autoload, ajoute un index :

ALTER TABLE wp_options ADD INDEX autoload (autoload);

Avant d’ajouter un index, mesure l’avant/après avec EXPLAIN sur la requête problématique et surveille l’espace disque (les index prennent de la place).

Limiter les options autoload trop lourdes

Si une option autoload dépasse plusieurs centaines de Ko, demande-toi si elle doit vraiment se charger à chaque requête : passe-la en autoload = 'no' si possible. Teste en staging.

EXPLAIN et requêtes critiques

EXPLAIN SELECT p.IDFROM wp_posts pJOIN wp_postmeta pm ON pm.post_id = p.IDWHERE p.post_type = 'product' AND pm.meta_key = '_price';

Vérifie que l’index post_id_meta_key est bien utilisé.

Automatiser l’entretien pour une base durable

L’objectif est d’éviter de recommencer de zéro dans six mois. Tu peux automatiser :

• Purge des transients expirés hebdomadaire.
• Limitation des révisions via WP_POST_REVISIONS.
• OPTIMIZE/ANALYZE mensuels sur les tables critiques.
• Alertes sur la taille des tables (seuils d’alerte).

Exemple avec WP-CLI + cron

# Script bash /usr/local/bin/wp-db-care.shwp transient delete --expiredwp db optimize# Cron (Linux) – chaque dimanche à 3h1515 3 * * 0 /usr/local/bin/wp-db-care.sh > /var/log/wp-db-care.log 2>&1

Tu peux aussi planifier un ANALYZE trimestriel sur les tables volumineuses et envoyer un rapport par e-mail avec les tailles avant/après.

Contrôles post-nettoyage : valider que tout va bien

• Front : pages clés, recherche, panier, tunnel de commande.
• Back : édition d’articles, médias, réglages d’extensions.
• Logs : erreurs PHP/MySQL, 24 à 48 h après.
• Perf : temps TTFB, requêtes lentes (<= 200 ms pour la plupart des SELECT courants).
• Sauvegardes : nouvelle taille, durée d’export.

Erreurs fréquentes à éviter

• Supprimer des tables sans sauvegarde ni renommage préalable.
• Lancer OPTIMIZE en pleine pointe de trafic.
• Ajouter trop d’index inutiles (coût d’écriture, espace disque).
• Nettoyer en prod sans test de restauration.
• Ignorer les options autoload très lourdes.

Quand déléguer à un pro (et gagner des heures)

Si ton site est e-commerce, multi-langue, ou très personnalisé, chaque minute d’indisponibilité coûte cher. Dans ces cas, déléguer le nettoyage et l’optimisation à une équipe qui fait ça tous les jours a du sens. Chez WP Builders, on suit une procédure standard : sauvegarde validée, environnement de test, nettoyage par lots, optimisation mesurée, reporting et plan de maintenance. Tu gardes le contrôle, on gère la technique.

En appliquant cette méthode (sauvegarder, auditer, nettoyer, optimiser, automatiser), tu donneras un vrai bol d’air à ta base de données WordPress et tu stabiliseras les performances sur le long terme.