Optimiser la table wp_options et les données de type « autoload »

La table wp_options stocke les options de WordPress, des extensions et des thèmes. Certaines sont chargées ensemble en autoload pour éviter des recherches répétées. Si cet ensemble devient trop volumineux, il peut augmenter le travail de lecture, de désérialisation et la mémoire, même si vous utilisez un cache d'objets.

Chaque option n'est pas forcément lue séparément ni à chaque accès au serveur : WordPress réutilise l'ensemble alloptions, et un cache de page peut éviter complètement d'exécuter WordPress.

Mesurer sans modifier les données

Vérifiez le préfixe de votre installation. Les exemples utilisent wp_options ; en multisite, vous devez identifier le site et la table correspondante. Depuis l'onglet SQL de phpMyAdmin, calculez le nombre et les octets :

SELECT COUNT(*) AS opciones,
       COALESCE(SUM(OCTET_LENGTH(option_value)), 0) AS bytes,
       ROUND(COALESCE(SUM(OCTET_LENGTH(option_value)), 0) / 1024, 2) AS kib
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

La requête inclut les valeurs que WordPress considère aujourd'hui comme chargées automatiquement par défaut. Une installation peut les filtrer ; consultez la fonction des valeurs autoload et le comportement de votre version.

La Santé du site peut avertir si l'ensemble dépasse son seuil, qui dépend de la version et des filtres. Aucune taille universelle ne garantit un problème : rapprochez la mesure de la mémoire et des temps réels.

Repérer les options volumineuses

SELECT option_name, autoload,
       OCTET_LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY OCTET_LENGTH(option_value) DESC
LIMIT 20;

Commencez par les noms et les tailles. Vous n'avez pas besoin d'exporter les valeurs complètes pour établir les priorités ; elles peuvent contenir des identifiants ou des données d'utilisateurs.

Identifiez l'extension ou le thème responsable en cherchant le nom exact dans son code et sa documentation. Désactivé ne veut pas dire abandonné : ses données peuvent être nécessaires s'il est réactivé. Testez un nettoyage ou un changement d'autoload sur un clone avec une sauvegarde restaurable, en utilisant l'API de WordPress ou l'outil du composant.

Ne modifiez pas les valeurs sérialisées et ne passez pas en masse toutes les options en non-autoload. Vous pourriez casser des données ou remplacer un chargement groupé par de nombreuses requêtes individuelles.

Examiner toute la table

Si l'autoload n'explique pas la taille, relancez la requête sans le filtre :

SELECT option_name, autoload,
       OCTET_LENGTH(option_value) AS bytes
FROM wp_options
ORDER BY OCTET_LENGTH(option_value) DESC
LIMIT 20;

Les octets des valeurs n'incluent pas tout l'espace de la table et des index. Les comptages qu'affiche un outil pour InnoDB peuvent être estimés ; utilisez COUNT(*) quand vous avez besoin d'un comptage exact, en tenant compte de son coût sur les grandes tables.

Cron, transients et sessions

Si l'option cron grossit, examinez les tâches planifiées et le composant qui les ajoute. Ne supprimez pas et ne modifiez pas sa structure sérialisée. Le guide de WP-Cron explique comment changer le déclencheur sans arrêter les tâches nécessaires.

Les transients ont une durée de vie maximale et peuvent disparaître avant. Selon la configuration, ils sont stockés dans des tables ou dans un cache persistant ; ils ne sont pas tous supprimés dès qu'ils atteignent leur date. Pour les examiner sans afficher les valeurs :

wp transient list --fields=name,expiration

Si vous avez validé la sauvegarde et devez supprimer ceux qui ont expiré, utilisez wp transient delete --expired. S'ils réapparaissent en excès, corrigez le composant qui les génère.

Les lignes de sessions dépendent de l'extension ; ce ne sont pas forcément les connexions standard de WordPress. Un nettoyage générique basé sur une ressemblance de nom peut faire perdre des paniers ou un travail en cours. Utilisez la durée de conservation et l'outil du composant responsable.

Index et Redis

WordPress crée déjà des index sur ses tables. Avant d'en ajouter un autre, vérifiez ceux qui existent :

SHOW INDEX FROM wp_options;

Examinez le plan de la requête lente avec EXPLAIN et testez tout index sur un clone. N'ajoutez pas un index composé simplement parce que la table est volumineuse : il coûte aussi de l'espace et du travail à chaque écriture.

Le cache d'objets avec Redis peut réduire les lectures répétées, mais il ne dispense pas d'examiner un ensemble d'options disproportionné. Après chaque modification, comparez les temps, la mémoire, la configuration et les tâches pour vérifier que l'amélioration n'a pas modifié le fonctionnement.