SELECT COUNT(*) FROM wp_postmeta; a renvoyé un peu plus de 38 millions de lignes. Sur un catalogue de 60 000 variations produit, cela représentait plus de 600 meta par variation en moyenne — un rapport qui aurait dû alerter bien avant que les pages produit ne mettent quatre secondes à s’afficher.
La boutique vendait du matériel professionnel avec un système de configuration complexe : chaque variation portait des dizaines d’attributs techniques stockés en meta individuelles, accumulées sur plusieurs années sans jamais avoir été purgées des versions obsolètes lors des mises à jour de fiches produit.
Où regarder avant de supprimer quoi que ce soit
La tentation immédiate aurait été de lancer un DELETE massif sur les meta suspectes. Mauvaise idée sans audit préalable : certaines meta apparemment inutilisées sont en réalité lues par des extensions tierces (comparateur de prix, module de recommandation) qui ne les affichent pas dans l’interface mais s’appuient dessus en arrière-plan.
L’audit a commencé par un classement des meta_key par volumétrie, pour identifier les postes les plus lourds :
SELECT meta_key, COUNT(*) AS nb, ROUND(SUM(LENGTH(meta_value))/1024/1024, 2) AS mo
FROM wp_postmeta
GROUP BY meta_key
ORDER BY mo DESC
LIMIT 20;Le vrai coupable : un historique de versions de configurateur
Le résultat de cette requête a désigné un coupable inattendu : une meta _configurator_snapshot_v1, _configurator_snapshot_v2, et ainsi de suite jusqu’à _configurator_snapshot_v14, générées par un module de configuration produit maison qui enregistrait un instantané complet de l’état du configurateur à chaque modification de fiche, sans jamais supprimer les anciennes versions. À elle seule, cette série de meta représentait 27 des 40 Go.
Ces instantanés n’étaient utiles que pour un historique de débogage rarement consulté. La décision a été de conserver uniquement les trois dernières versions par produit et d’archiver le reste hors base, dans un stockage de fichiers plat, avec un script de migration exécuté hors heures de trafic.
Migrer plutôt que supprimer : la table dédiée
Pour les meta réellement utiles mais volumineuses — les caractéristiques techniques détaillées de chaque variation — la solution n’a pas été la suppression mais la migration vers une table dédiée, wp_product_specs, avec un index sur product_id et spec_key. Cette table, hors du schéma générique wp_postmeta, permet des requêtes bien plus rapides car elle ne porte que des colonnes typées pour cet usage, sans la structure clé-valeur générique de wp_postmeta qui oblige à scanner des lignes non pertinentes.
- Étape 1 : créer la table dédiée avec un schéma adapté aux données réelles.
- Étape 2 : migrer les données par lots de 5 000 lignes, hors heures de pointe, avec vérification de cohérence après chaque lot.
- Étape 3 : rediriger la lecture applicative vers la nouvelle table via une classe d’accès dédiée.
- Étape 4 : supprimer les meta migrées de
wp_postmetaseulement après validation complète en production sur une période de deux semaines.
Reconstruire les index après, pas avant
Point souvent négligé : lancer un OPTIMIZE TABLE wp_postmeta avant d’avoir terminé toutes les suppressions gaspille du temps, car chaque suppression massive suivante fragmente à nouveau la table. L’optimisation n’a été exécutée qu’une fois l’ensemble du nettoyage terminé, en une seule passe, sur un créneau de maintenance nocturne, la table étant temporairement verrouillée en écriture pendant l’opération sur ce moteur de stockage.
Conseil maison : avant tout nettoyage de
wp_postmetasur un catalogue volumineux, classez toujours par volumétrie avant d’agir sur la fréquence d’accès. Une meta rarement lue mais énorme fait souvent plus de dégâts qu’une meta lue souvent mais légère.
En résumé
Une table wp_postmeta de 40 Go n’est presque jamais uniformément lourde : elle cache généralement un ou deux postes qui concentrent l’essentiel du volume, souvent issus d’un historique jamais purgé plutôt que d’un usage légitime continu. L’audit par volumétrie avant toute suppression, puis la migration des données réellement utiles vers une table dédiée, ont ramené le temps d’affichage d’une fiche produit de quatre secondes à moins de six cents millisecondes. L’optimisation des requêtes de recherche du catalogue reste un chantier séparé, mené une fois cette base assainie.
