Lorsqu’un client signale la lenteur des écrans d’administration, l’échec des vérifications ou des délais d’attente aléatoires, les agences n’ont pas le luxe de fouiller dans des dizaines de tables ou de faire de la rétro-ingénierie sur le comportement des extensions. Vous devez reconnaître rapidement les points d’échec probables et concentrer votre attention là où c’est important.
En pratique, la plupart des problèmes graves de performance et de stabilité sont liés à un petit nombre de tables de base de données qui se développent sans contrôle au fil du temps. Ces tables ne posent pas de problèmes sur les sites nouveaux ou à faible trafic, mais avec des années de contenu, d’extensions et d’activité des utilisateurs, elles sont responsables d’un nombre disproportionné de pannes, de requêtes lentes et de tickets d’assistance d’urgence.
Cet article se concentre sur cinq tables de base de données WordPress (et modèles de tables) que les agences de maintenance devraient surveiller activement parce qu’elles sont les plus susceptibles de causer des problèmes de performance au fur et à mesure que les sites grandissent.
Pourquoi les agences n’ont besoin de surveiller que 20 % de la base de données
Le principe de Pareto permet d’expliquer de nombreux schémas opérationnels, et il s’applique également à la maintenance des bases de données WordPress. Les agences ne rencontrent pas de problèmes de manière uniforme sur l’ensemble de la base de données. C’est plutôt un petit sous-ensemble de tables qui est à l’origine de la plupart des ralentissements, des pannes et des tickets de support urgents liés à la base de données.
Les installations standard de WordPress créent 12 tables par défaut. Certaines, telles que wp_users, wp_links, et les tables de taxonomie, peuvent fonctionner pendant des années sans causer de problèmes. Elles ne déclenchent généralement pas les requêtes les plus lentes qui font planter les sites lors des pics de trafic.
Cependant, les tables à haut risque ont une caractéristique commune : elles peuvent endommager les sites à grande échelle. Un site contenant 100 articles peut fonctionner correctement avec des révisions illimitées. Ce même site, avec 10.000 articles et 300.000 entrées de révision, risque de s’arrêter à chaque écran de modification. Une boutique de commerce électronique de 50 produits devrait fonctionner correctement, mais si elle passe à 5000 produits, le chargement des pages peut prendre plusieurs secondes.
Cinq modèles de base de données qui font échouer les sites WordPress à grande échelle
Examinons cinq modèles qui apparaissent fréquemment dans les travaux de maintenance des agences.
Ils ne sont pas immédiatement dangereux sur les petits sites, mais au fur et à mesure que le contenu, le trafic et l’activité des extensions augmentent, ils deviennent les sources les plus courantes de requêtes lentes, de dépassements de délais et de problèmes de stabilité.
wp_options : le gonflement de l’autoload pourrait faire planter les sites à fort trafic
La table wp_options stocke les réglages du site et les configurations des extensions et détermine les options que WordPress charge à chaque requête de page (y compris les pages en cache). Parmi les colonnes, autoload est la plus importante :
WordPress charge d’abord toutes les options autoload en mémoire à chaque requête. Les sites avec des empreintes autoload plus petites peuvent gérer le trafic normalement, bien que lorsque l’autoload augmente, chaque visiteur consomme plus de mémoire que ce que votre serveur alloue par processus PHP.
Si la taille de l’autoload devient trop importante (disons qu’elle dépasse 3 Mo ou plus), vous verrez des écrans d’administration lents, des échecs de paiement pendant les ventes, et des erreurs 502.
Le coupable est presque toujours un plugin orphelin ou des entrées de cache temporaires connues sous le nom de « transients ». Avec l’autoload activé, certaines options d’extension que vous supprimez peuvent rester dans la table wp_options, ce qui signifie qu’elles se chargent à chaque requête. Si vous utilisez des dizaines d’extensions pendant des mois ou des années, vous accumulez des données abandonnées qui se chargent à chaque fois qu’une page est consultée.
La console SQL de Database Studio illustrée ci-dessus vous permet d’exécuter une requête pour vérifier la taille des données chargées automatiquement en octets :
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Vous pouvez utiliser la console pour effectuer d’autres requêtes, par exemple pour trier les résultats de la requête initiale.
Votre plan ici devrait être d’examiner les résultats, d’identifier les grandes entrées de chargement automatique, et de les nettoyer (c.-à-d., supprimer les lignes).
wp_postmeta : Les sites de commerce électronique peuvent s’effondrer à cause d’un gonflement des métadonnées
La table wp_postmeta stocke les champs personnalisés pour les articles, les pages et les produits. Chaque fois qu’un contenu est enregistré, de nouvelles entrées de métadonnées peuvent être ajoutées. Les extensions, en particulier, attachent souvent des dizaines de champs à un seul article ou produit.
Par exemple, WooCommerce stocke des données sur les produits dans postmeta : variations, inventaire, détails d’expédition et attributs. Un seul produit avec des variations peut générer des dizaines d’entrées de métadonnées. Les grands catalogues de produits créent potentiellement des millions de lignes de postmeta.
Le résultat d’une table wp_postmeta en pleine expansion est que les écrans d’édition peinent à charger les données, que les filtres de produits ralentissent et que les recherches s’interrompent lorsqu’elles tentent d’effectuer des requêtes dans des tables volumineuses. En général, les erreurs qui surviennent pendant les périodes de fort trafic sont dues au gonflement de wp_postmeta.
À l’aide de la console SQL, vous pouvez exécuter des requêtes pour sélectionner et supprimer des données superflues, comme dans le cas de wp_options. Vous recherchez des aspects tels que des tables postmeta de plusieurs gigaoctets, de nombreux doublons meta_keys, et des métadonnées orphelines en général. Les options de filtrage de Database Studio sont également utiles à cet égard :
Par exemple, vous pouvez trier par meta_key en cliquant sur la flèche de la colonne. Les clés identiques sont ainsi regroupées, ce qui vous permet de repérer des modèles, tels que les clés des extensions supprimées ou des champs personnalisés inutilisés.
wp_posts : révisions illimitées écrans d’édition de crash
La table wp_posts stocke le contenu et l’historique des révisions. Par défaut, WordPress enregistre chaque modification comme une entrée de base de données distincte, de sorte que l’édition régulière de contenu génère une quantité importante de données supplémentaires. Les sites avec des historiques de contenu et d’édition étendus peuvent accumuler des milliers d’entrées de révision.
Au départ, vos sites fonctionnent correctement, mais le fait d’avoir de nombreuses révisions enregistrées peut ralentir le chargement de vos écrans d’administration lors de l’édition d’articles. WordPress enregistre toutes les 60 secondes pendant l’édition ; les sauvegardes automatiques peuvent également avoir un impact négatif car de longues sessions d’édition créent des dizaines d’entrées de sauvegarde automatique.
Vous pouvez rapidement élaguer la table de révisions wp_posts (par exemple) :
Vous pouvez ensuite passer à la console SQL pour exécuter une requête et supprimer les révisions :
DELETE FROM wp_posts WHERE post_type="revision";
C’est une bonne idée de comparer le nombre de révisions à vos articles publiés : des ratios à un chiffre sont raisonnables. Vérifiez également si les révisions représentent plus de la moitié du nombre total d’entrées, car cela indique un gonflement probable. Les révisions qui augmentent d’un mois sur l’autre suggèrent la nécessité de mettre en place des limites, ce que vous pouvez faire en modifiant rapidement wp-config.php.
Tables de plugins : les formulaires et les journaux grossissent jusqu’à ce que votre site tombe en panne
Presque toutes les extensions créent des tables de base de données personnalisées, mais c’est plus courant avec les extensions de formulaire, de recherche et de sécurité. Celles-ci peuvent continuer à croître sans nécessiter de maintenance intégrée.
En particulier, les extensions de formulaire stockent par défaut tous les envois de manière permanente. Ainsi, si vos sites reçoivent un trafic d’envoi régulier pendant des années, vous accumulez des milliers d’entrées de formulaire. De plus, les tables liées aux journaux se développent encore plus rapidement. Les extensions de sécurité enregistrent les actions des visiteurs, les extensions d’analyse suivent les pages vues et les outils de débogage enregistrent les erreurs.
Comme c’est souvent le cas pour les problèmes liés aux tables de base de données, les pages s’interrompent, mais vous constatez également que les sauvegardes de la base de données sont lentes et que la dégradation des performances n’est pas en rapport avec le trafic. Le lien avec le gonflement de la base de données n’est pas toujours évident, car les symptômes apparaissent dans des domaines sans rapport les uns avec les autres.
Vous devez rechercher les tables des extensions qui correspondent ou dépassent la taille des tables principales de WordPress ; plus elles sont grandes, plus il est important de les réduire. Une requête SQL peut les identifier pour vous :
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Si l’une d’entre elles est orpheline, vous pouvez la supprimer en toute sécurité. Cependant, bien que cela dépasse le cadre de cet article, si des tables sont suffisamment grandes pour être réduites mais qu’elles sont toujours nécessaires sur votre site, vous devrez faire des recherches sur l’une d’entre elles – et éventuellement contacter le développeur pour obtenir des conseils.
Action Scheduler : les tâches échouées s’accumulent et font planter la vérification
Action Scheduler exécute essentiellement des tâches d’arrière-plan pour WordPress. Il met les tâches en file d’attente, les traite de manière asynchrone et stocke les enregistrements d’achèvement de manière permanente par défaut.
L’utilisation de WooCommerce est un excellent moyen de comprendre comment Action Scheduler peut causer des problèmes. Par exemple, les délais de la passerelle de paiement entraînent l’échec des actions qui persistent dans la base de données et sont interrogées à chaque chargement de page pour vérifier les travaux en cours. Vous pouvez extrapoler une seule action échouée parmi les milliers d’actions qu’une boutique WooCommerce typique génère par mois.
Database Studio’s Views peut vous aider à supprimer ces actions échouées :
Ici, donnez un titre à la vue, choisissez la table wp_actionscheduler_actions, puis cliquez sur le lien Ajouter une condition. Cela vous permet de n’afficher que les actions qui ont échoué, ce qui simplifie grandement leur suppression de la base de données.
Comment gérer les tables importantes de votre base de données WordPress en 10 minutes par mois
Pour quelques minutes par mois, vous pouvez gérer moins de bases de données sur une année. Bien sûr, vous n’avez pas besoin de surveiller ou de gérer de nombreuses tables de votre base de données :
- La table
wp_userspose rarement des problèmes, sauf si vous gérez des sites d’adhésion comportant des millions de comptes. Les données relatives aux utilisateurs augmentent généralement de façon linéaire sans s’alourdir. - Les tables de taxonomie (telles que
wp_terms,wp_term_taxonomy,wp_term_relationships) restent souvent stables quelle que soit la taille du site.
Parmi les cinq tables problématiques, les grandes tables wp_posts sur les sites de contenu sont typiques et attendues. N’oubliez pas que le contenu réel n’est pas un gonflement.
Mise en place de votre flux de travail de surveillance
L’exportation des tables de votre base de données vous permet de travailler avec les données dans d’autres applications. Vous pouvez le faire à partir du menu déroulant Plus d’éléments de n’importe quelle table :
Cependant, vous pouvez accomplir beaucoup de choses dans MyKinsta sans exporter. La meilleure façon d’utiliser votre temps est d’automatiser le nettoyage et d’examiner manuellement les mesures de votre base de données. Les vues de Database Studio peuvent vous aider à configurer votre analyse.
Par exemple, vous pouvez créer une vue personnalisée qui surveille wp_postmeta et ajouter des filtres pour les modèles meta_key spécifiques que vous souhaitez suivre :
Database Studio vous permet de créer et d’enregistrer des extraits dans la console SQL, de sorte que vous pouvez configurer une requête SQL pour trier toutes les tables par taille et y accéder à tout moment :
Les tables les plus volumineuses sont wp_posts, wp_postmeta et wp_options. Vous devez examiner toutes les tables qui sont les plus volumineuses.
La surveillance exacte que vous mettez en place dépend de vos sites et de vos besoins. Toutefois, voici quelques domaines à surveiller :
- Filtrez
wp_optionspour les chargements automatiques actifs, puis vérifiez la taille totale (soit par des requêtes SQL, soit par l’exportation au format CSV). Tout ce qui dépasse 1 Mo doit être examiné. - Vérifiez la taille de la table
wp_postmetapar rapport à celle du mois précédent, en particulier pour détecter les augmentations de taille importantes. - Vous pouvez filtrer post_type dans
wp_postspour comparer les révisions des publications. Si nécessaire, fixez une limite danswp-config.php. - Pour le planificateur d’actions, les actions terminées doivent être plus nombreuses que les actions en attente ou qui ont échoué.
En résumé, utilisez Database Studio pour créer les vues, les filtres et les extraits de requête que vous utiliserez souvent. Ensuite, recherchez les mesures « dangereuses », puis utilisez d’autres outils pour automatiser le nettoyage. Par exemple, la commande WP-CLI wp transient delete peut vous aider à éliminer les transients indésirables dans la base de données.
De la correction réactive à la maintenance proactive des bases de données
Les problèmes de base de données auxquels les agences sont le plus souvent confrontées ne sont pas rares ou imprévisibles. Ils sont le résultat de schémas familiers. La différence entre réagir à ces problèmes et les prévenir se résume à une question de concentration.
Il n’est pas nécessaire d’inspecter chaque table ou d’auditer chaque requête. Vous devez savoir quelles parties de la base de données méritent une attention permanente et comment repérer les signes avant-coureurs avant qu’ils ne se transforment en pannes ou en demandes de support d’urgence.
Pour les agences de maintenance, cela modifie la façon dont le travail sur les bases de données s’inscrit dans votre flux de travail. Au lieu de considérer le nettoyage de la base de données comme une réparation ponctuelle après une panne, il devient un contrôle léger et reproductible.
Si vous rencontrez un problème de base de données que vous ne pouvez pas résoudre, en particulier un problème qui n’apparaît qu’en cas de charge, il est important d’avoir le bon support. Pour les sites hébergés sur Kinsta, notre équipe de support est disponible 24/7 pour vous aider.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
