La base WordPress ralentit un site quand chaque page attend des requêtes avant d’envoyer le HTML. Le visiteur le perçoit comme un temps jusqu’au premier octet trop long, pas comme un JPEG lourd. On ne « nettoie tout » au hasard. On confirme que la base est bien l’étage lent, on mesure deux ou trois tables qui grossissent toujours, puis on purge ce qui n’est pas du contenu, après une sauvegarde.
Confirmer que la base est en cause
Comparez une page HTML et un fichier statique du même site (une image ou une feuille CSS). Si le statique part tout de suite et le HTML non, le délai est dans PHP et MySQL, pas dans le réseau. L’ordre général de ce diagnostic est dans page lente : causes.
Sur un environnement de préproduction ou avec un compte administrateur, Query Monitor liste les requêtes de la page, leur durée, et celles qui se répètent. En production, le journal des requêtes lentes de MySQL (slow_query_log) donne la même information sans l’afficher aux visiteurs. Notez le texte SQL et le nombre de lignes lues. Une requête qui examine des dizaines de milliers de lignes pour en rendre dix est un candidat. Une requête d’une milliseconde répétée deux cents fois à cause d’une boucle dans le thème en est un autre.
Tant que vous n’avez pas cette liste, vider une table au jugé ne se justifie pas.
Ce qui grossit sans être une page
Options autoloadées. WordPress charge à chaque requête les lignes de wp_options marquées pour l’autoload. Une option énorme (un réglage de constructeur, un cache mal rangé) est donc lue même sur une page qui ne s’en sert pas. On mesure le volume, on identifie les options anormalement grosses, on ne désactive pas l’autoload d’une option du cœur sans savoir à quoi elle sert.
Révisions. Chaque enregistrement d’article peut créer une ligne post_type = revision. Elles aident à revenir en arrière. Au-delà d’un petit nombre par article, elles n’aident plus l’affichage. La constante WP_POST_REVISIONS en fixe le plafond pour la suite. La purge des anciennes révisions se fait après export de la base, de préférence avec WP-CLI (wp post delete sur le type revision), qui nettoie aussi les métadonnées liées. Un DELETE SQL écrit à la main oublie souvent wp_postmeta.
Transients et files. Les transients expirés restent dans wp_options jusqu’à un nettoyage. Les tables Action Scheduler (wp_actionscheduler_actions, courantes avec WooCommerce) accumulent des tâches terminées. Les purger retire de l’historique de tâches, pas les commandes. Là encore : sauvegarde, puis outil prévu (WP-CLI ou l’écran de l’extension), pas un vidage de wp_posts.
Les commentaires indésirables en masse se traitent par l’écran commentaires ou WP-CLI. Ils gonflent wp_comments et peuvent ralentir l’administration plus que la page publique mise en cache.
Index et cache d’objets
wp_postmeta est indexé sur post_id et meta_key, pas sur meta_value. Une requête du type « toutes les fiches dont la meta couleur vaut bleu », écrite par une extension, peut parcourir la table. L’index utile dépend de la requête exacte : on l’ajoute pour cette requête, on ne pose pas un index sur toute colonne « parce que c’est plus rapide ». Un index inutile ralentit les écritures.
Un cache d’objets (Redis, Memcached) garde en mémoire le résultat de lectures répétées, dont les options. Il masque une partie du coût. Il ne corrige pas le schéma. Après un trou de cache, la requête lourde revient. Mettez le cache quand les mêmes lectures reviennent sur chaque page, et gardez l’index ou la réécriture SQL pour la requête qui lit trop de lignes.
Mesurez le TTFB après le nettoyage, sur la même URL, hors cache navigateur. Une impression de rapidité dans l’administration ne prouve pas que la page anonyme a changé. SiteGarde peut suivre ce temps de réponse dans la durée, une fois le correctif en place. Il ne voit pas le plan d’exécution SQL.