La base WooCommerce grossit sans raison apparente : trouver le producteur avant de supprimer des données

Une base volumineuse et une base qui grossit sont deux problèmes distincts

Cette distinction est importante.

Une base WooCommerce peut être volumineuse pour des raisons légitimes :

• des années de commandes
• de grands catalogues de produits
• des métadonnées de lignes de commande
• des clients
• des données analytiques
• des journaux opérationnels
• des enregistrements métier personnalisés
• des intégrations historiques

Cela ne signifie pas automatiquement que les données sont inutiles.

Une base qui grossit activement est un incident différent.

Quelque chose continue d’écrire des données.

Il peut s’agir d’une croissance normale de l’activité, mais aussi :

• d’un processus planifié qui produit des enregistrements plus vite que le nettoyage ne les retire
• de tâches de fond qui échouent à répétition
• de sessions conservées plus longtemps que prévu
• d’un plugin écrivant des journaux sans limite
• de transients ou d’options qui s’accumulent
• d’imports produisant à répétition des métadonnées
• d’une synchronisation en double
• d’une table personnalisée sans politique de conservation
• d’une migration ou d’un rattrapage de données qui replanifie du travail à répétition

La plus grande table n’est donc pas nécessairement celle qui provoque l’incident.

La table la plus importante peut être celle qui grossit le plus vite.

Commencer par le rythme de croissance, pas par la taille totale

Imaginons deux tables.

L’une contient plusieurs gigaoctets de données historiques de commandes légitimes et change à peine chaque jour.

L’autre ne fait que quelques centaines de mégaoctets, mais reçoit continuellement des données.

La plus petite mérite généralement d’être examinée d’abord, car son rythme de croissance courant représente le risque actif.

Pour une croissance inattendue, prenez au moins deux instantanés horodatés.

Relevez :

• la taille totale de la base
• le nom de la table
• la taille des données
• la taille des index lorsqu’elle est disponible
• le nombre approximatif de lignes
• l’horodatage

Comparez-les après un intervalle adapté.

L’objectif est de transformer :

« La base semble énorme. »

en un constat plus utile :

« Cette table a ajouté l’essentiel du nouveau stockage pendant la période observée. »

Cela réduit immédiatement le périmètre de l’investigation.

Une requête en lecture seule peut aider à établir le point de départ :

SELECT
    table_name,
    table_rows,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

Pour les tables InnoDB, considérez table_rows comme une estimation, pas comme un décompte exact. DATA_LENGTH et INDEX_LENGTH sont aussi des estimations d’espace alloué fournies par le moteur, et les statistiques de table INFORMATION_SCHEMA peuvent être mises en cache. Utilisez la même méthode de mesure pour comparer les instantanés afin que la tendance soit comparable. Ne traitez pas ces valeurs comme un nombre exact d’octets récupérables sur disque.

L’élément important est la variation entre les observations, pas l’affichage d’un décompte parfaitement précis dans un écran d’administration.

Établir une fiche caractéristique de la croissance de la base

Une fois les tables qui changent identifiées, classez-les.

Une fiche d’investigation utile ressemble à ceci :

Cela produit une description du problème bien plus solide que :

[prefix]actionscheduler_actions occupe 4GB.

Un constat utile serait plutôt :

Un hook précis d’actions planifiées génère continuellement des enregistrements. Les actions terminées s’accumulent plus vite que la conservation ne les retire, et cette production a commencé après un changement de parcours précis.

Vous disposez maintenant d’un constat à investiguer.

Identifier le propriétaire de la table qui grossit

WordPress et WooCommerce répartissent les données entre les tables du cœur WordPress et des tables propres à WooCommerce. Les noms des tables WooCommerce utilisent le préfixe de base configuré pour le site, souvent wp_, mais pas toujours.

WooCommerce utilise des tables dédiées pour les sessions client, webhooks, stocks réservés et analyses. Lorsque High-Performance Order Storage est le stockage actif des commandes, leurs données sont conservées dans des tables dédiées telles que wc_orders, wc_order_addresses, wc_order_operational_data et wc_orders_meta (avec le préfixe de base du site ajouté devant).

Les plugins peuvent également ajouter leurs propres tables.

Le propriétaire de la table est donc l’un des premiers indices utiles.

Tables du cœur WordPress

Exemples :

• wp_options
• wp_posts
• wp_postmeta
• wp_users
• wp_usermeta
• tables de taxonomie

La croissance peut néanmoins y être provoquée par une extension WooCommerce ou un plugin personnalisé.

Le nom de la table indique où les données sont stockées.

Il n’indique pas nécessairement qui les a produites.

Tables WooCommerce

Exemples :

• tables de commandes
• tables de recherche et de rapports sur les commandes
• woocommerce_sessions
• tables de webhooks
• données de stock réservé

La documentation WooCommerce identifie woocommerce_sessions explicitement comme le stockage des informations de session client, notamment le contenu du panier et les variables de session.

Tables Action Scheduler

Elles comprennent généralement des tables pour :

• les actions planifiées
• les journaux d’actions
• les réservations de traitement
• les groupes

WooCommerce et de nombreuses extensions utilisent Action Scheduler pour le travail asynchrone.

Tables propres aux plugins

Elles constituent souvent le chemin le plus rapide vers le propriétaire.

Un préfixe distinctif peut orienter directement vers :

• un plugin d’analyse
• un système de recherche ou d’indexation
• un générateur de flux
• un outil d’import/export
• un système de paniers abandonnés
• un produit de journalisation
• une intégration
• des fonctionnalités applicatives personnalisées

Une fois le composant identifié, examinez son modèle de données et son cycle de vie avant toute suppression.

Si Action Scheduler grossit, examiner le travail avant de supprimer la file

Action Scheduler mérite une attention particulière dans les boutiques WooCommerce récentes.

L’équipe d’ingénierie WooCommerce indiquait en juin 2026 que les tables Action Scheduler comptaient parmi les plus sollicitées de nombreuses bases et que les boutiques à fort volume pouvaient produire des données plus vite que le nettoyage ne suivait. Action Scheduler 4.0 a modifié la conservation des actions échouées et fait évoluer le nettoyage vers un modèle plus évolutif.

Une table Action Scheduler volumineuse ne signifie pas automatiquement que le planificateur lui-même est la cause racine.

Action Scheduler est la file.

Il faut encore identifier le producteur du travail.

Ouvrez :

WooCommerce → Status → Scheduled Actions

et examinez :

• l’état
• le hook
• le groupe
• la planification
• les arguments pertinents
• les journaux associés

Demandez-vous :

Les actions sont-elles Pending ?

Le producteur peut planifier les tâches plus vite que les workers ne les traitent.

Ou le traitement de la file peut être défaillant.

Sont-elles Failed ?

Trouvez l’échec récurrent.

Supprimer les actions échouées sans corriger l’opération responsable ne fait que retirer des éléments de diagnostic.

Sont-elles majoritairement Complete ?

La file peut fonctionner correctement alors qu’un parcours produit un volume anormal de travail.

C’est un problème très différent d’une file bloquée.

Quel hook domine ?

C’est souvent l’indice le plus utile.

Le hook ou les arguments d’action peuvent relier la croissance à :

• WooCommerce lui-même
• une extension
• une intégration
• les analyses
• des imports
• des e-mails
• des abonnements
• des traitements de fond personnalisés

La bonne question devient :

Pourquoi ce parcours planifie-t-il autant de travail ?

et non :

Comment vider Action Scheduler ?

Comprendre le modèle de nettoyage actuel d’Action Scheduler

Le comportement de conservation a changé.

Avant Action Scheduler 4.0, les actions échouées étaient conservées indéfiniment par défaut, sauf modification du nettoyage par le code du site.

Depuis Action Scheduler 4.0, les actions échouées sont conservées trois mois par défaut. Le nettoyage a été déplacé vers une tâche quotidienne dédiée, conçue pour rattraper plus fiablement le retard sur les grandes tables.

Ce point compte lorsque vous consultez d’anciens conseils de dépannage.

Un article rédigé plusieurs années auparavant peut décrire une conservation qui ne correspond plus à la version exécutée dans une boutique actuelle.

Avant de modifier vous-même la conservation, établissez donc :

• quelle version d’Action Scheduler s’exécute
• quel composant l’embarque ou la charge
• si des filtres personnalisés modifient la conservation
• quels états dominent la table
• si le nettoyage s’exécute réellement

Le comportement propre à la version fait partie du diagnostic.

wp_options : croissance ne signifie pas surcharge de l’autoload

Une autre erreur fréquente consiste à voir une table volumineuse wp_options et à considérer immédiatement l’ensemble de la table comme un problème d’autoload.

Ces questions sont liées, mais distinctes.

wp_options peut contenir :

• des réglages WordPress
• des réglages de thème
• des réglages de plugins
• des données de transients
• des états applicatifs en cache
• des enregistrements propres à des extensions

Certaines options sont chargées automatiquement au démarrage de WordPress.

Les recommandations actuelles de performance WordPress avertissent qu’un excès d’options autoloadées peut nuire aux performances et donnent comme repère général un volume inférieur à environ 800 KB.

Une table wp_options de 500 MB ne signifie pas que WordPress charge automatiquement 500 MB à chaque requête.

Mesurez séparément le volume autoloadé.

Examinez ensuite ce qui produit la croissance de la table.

Recherchez des préfixes récurrents de noms d’options ou des familles d’enregistrements.

Ces préfixes révèlent souvent :

• un plugin
• une famille de transients
• un espace de noms de cache
• des données en file
• une configuration obsolète
• un état généré

Si un préfixe ajoute des milliers de lignes, examinez pourquoi le composant les écrit et ce qui devrait les faire expirer.

Ne commencez pas par supprimer des options inconnues parce que leurs noms semblent temporaires.

Les transients sont temporaires par conception, mais leur stockage exige du contexte

Les transients WordPress sont destinés aux données temporaires en cache.

Selon la configuration du cache d’objets, les transients peuvent être stockés en base plutôt que dans un cache d’objets persistant externe. Sans ce dernier, WordPress les conserve généralement dans wp_options. Par défaut, les transients avec expiration ne sont pas autoloadés, contrairement à ceux sans expiration. Un usage intensif peut donc faire grossir la table d’options sans augmenter d’autant le volume autoloadé.

Si des enregistrements de type transient dominent une table en croissance wp_options , demandez-vous :

• quel composant les crée
• s’ils ont une expiration
• si l’expiration et le nettoyage fonctionnent
• si le rythme de création est anormal
• si un robot, un crawler, une combinaison de requêtes ou une clé de cache propre à un utilisateur produit des variantes sans limite
• si le plugin concerné est toujours actif

Nettoyer les transients expirés peut être approprié.

Mais si un processus les recrée plus vite qu’ils n’expirent, le nettoyage seul n’est pas la correction.

Traiter les sessions WooCommerce comme un état commercial actif

woocommerce_sessions exige encore davantage de prudence.

Cette table conserve les informations de session client, notamment l’état du panier.

WooCommerce a modifié la gestion des sessions dans la version 10.1, notamment avec une durée maximale de 30 jours et la migration de ses tâches Cron vers Action Scheduler pour rendre le nettoyage plus fiable et plus facile à diagnostiquer. WooCommerce reliait explicitement ces limites à la prévention de la croissance due à une conservation excessive des sessions.

Si la table de sessions grossit de manière inattendue, examinez :

• le rythme de création des sessions
• l’expiration des sessions
• si les actions de nettoyage s’exécutent
• le trafic de robots ou de crawlers qui crée des sessions
• le code personnalisé qui modifie l’expiration
• une persistance inhabituelle des paniers
• les changements de trafic

WooCommerce fournit un outil pour effacer les sessions client.

Cela ne signifie pas qu’effacer toutes les sessions actives doit être la première étape du diagnostic.

Cette action peut invalider les paniers et états de session des clients actifs.

Déterminez d’abord pourquoi la table grossit.

De grandes tables de commandes peuvent simplement refléter l’activité

Si les données qui grossissent le plus vite sont :

• wc_orders
• wc_orders_meta
• les lignes de commande
• des métadonnées de lignes de commande
• les enregistrements client

la croissance peut être attendue.

Une boutique qui traite plus de commandes doit créer davantage de données commerciales.

Ce n’est pas du gonflement inutile simplement parce que la base est plus grande que l’année précédente.

Les questions suivantes doivent être :

• La croissance est-elle proportionnelle au volume réel de commandes ?
• Les métadonnées sont-elles dupliquées anormalement ?
• Une extension associe-t-elle trop de données à chaque commande ?
• Des enregistrements temporaires ou de débogage sont-ils stockés à côté des données métier durables ?
• Une synchronisation historique duplique-t-elle le stockage des commandes ?
• Les exigences de conservation et les obligations légales sont-elles comprises ?

HPOS modifie l’architecture de stockage des commandes en déplaçant leurs données vers des tables WooCommerce dédiées aux charges de commerce électronique.

Mais HPOS n’est pas un bouton générique de nettoyage de la base.

Si la synchronisation de compatibilité est active pendant une migration ou en mode de compatibilité, les commandes peuvent être volontairement maintenues synchronisées entre les tables WooCommerce et le stockage WordPress fondé sur les articles.

Ce stockage supplémentaire a un contexte architectural.

Ne supprimez pas un côté parce qu’il semble dupliqué avant de comprendre quel stockage fait autorité et ce qu’exige le mode de compatibilité.

Les tables de plugins exigent une réflexion sur le cycle de vie des données

Les extensions WooCommerce personnalisées ont souvent besoin d’un stockage durable.

Ajouter des tables personnalisées n’a rien d’intrinsèquement problématique.

La véritable question d’ingénierie est de savoir si les données ont un cycle de vie.

Pour chaque type de données à fort volume, l’implémentation doit répondre à ces questions :

1. Pourquoi cet enregistrement est-il créé ?
2. Combien de temps est-il nécessaire ?
3. Qu’est-ce qui y fait référence ?
4. Peut-il être régénéré ?
5. Quand expire-t-il ?
6. Qu’est-ce qui le supprime ?
7. Que se passe-t-il si le nettoyage échoue ?
8. Comment une croissance anormale devient-elle visible ?

Cela s’applique :

• aux zones de préparation d’imports
• aux journaux de charges utiles d’API
• aux enregistrements de webhooks
• aux index de recherche
• aux contenus générés
• aux événements analytiques
• aux états de synchronisation
• aux journaux des tâches de fond
• aux correspondances temporaires
• aux historiques de nouvelles tentatives

Une table personnalisée qui n’implémente que la création et la lecture sans conception de conservation ou de nettoyage peut devenir un problème de production des mois après le succès apparent de la fonctionnalité.

Lorsque le producteur est du code personnalisé, la question de conception plus large relève de l’ingénierie des plugins et intégrations WooCommerce sur mesure : traitements sûrs en cas de répétition, nouvelles tentatives bornées, conservation, nettoyage et observabilité doivent être conçus ensemble.

Les journaux nécessitent eux aussi une conservation délibérée

Les données de débogage sont précieuses pendant un incident.

Les journaux conservés indéfiniment le sont rarement.

Si une table de journaux grossit :

• identifiez le composant qui écrit.
• établissez le niveau de journalisation.
• vérifiez si le débogage a été laissé actif.
• comprenez la conservation.
• déterminez si des échecs répétés produisent trop d’entrées.
• préservez les éléments nécessaires à l’incident actif avant toute réduction.

Ne désactivez pas simplement tous les journaux parce que le stockage se remplit.

Vous pourriez détruire les éléments nécessaires pour expliquer la défaillance.

Réduisez le volume inutile une fois la condition responsable comprise.

Taille de la base et performances ne sont pas identiques

Autre distinction utile :

Volumineux ne signifie pas automatiquement lent, et petit ne signifie pas automatiquement sain.

Une table très volumineuse interrogée efficacement n’est pas nécessairement la source d’un incident de performance visible.

Un jeu de données bien plus petit peut causer de graves problèmes si :

• des requêtes coûteuses le parcourent à répétition.
• des index importants manquent.
• une contention sur les verrous survient.
• le volume autoloadé est excessif.
• l’application écrit à répétition des données inutiles.
• un processus de fond entre en concurrence avec les requêtes de commande ou d’administration.

WordPress distingue lui-même l’excès d’options autoloadées comme un problème de performance spécifique, plutôt que de traiter tout le volume de la base de la même manière.

Gardez donc deux investigations distinctes :

Incident de stockage

Pourquoi la base grossit-elle ?

Incident de performance

Quelles opérations de base retardent les requêtes importantes ?

Elles peuvent partager une cause.

Mais pas nécessairement.

N’affirmez pas que retirer 2 GB accélérera automatiquement le tunnel sans mesures démontrant que les données supprimées étaient responsables de la charge lente.

Si la croissance s’accompagne de contention sur les verrous, de requêtes lentes, de pression sur les files ou d’instabilité, traitez-la dans une approche plus large de la performance WooCommerce et la remise en service en production plutôt que de supposer que le volume de stockage est à lui seul responsable des performances.

Les changements récents sont l’un des indices les plus forts

Si la base était stable puis a commencé à grossir soudainement, reconstituez la chronologie des changements.

Examinez :

• les installations de plugins
• les mises à jour de plugins
• les mises à jour WooCommerce
• les migrations
• la configuration HPOS
• les nouveaux imports
• les nouvelles intégrations
• les changements de journalisation
• les changements de Cron
• les changements de trafic
• les campagnes marketing
• l’activité des crawlers
• les déplacements de serveur
• les changements de comportement des sessions
• les nouvelles fonctions de traitement de fond

Comparez ensuite l’apparition de la première croissance anormale à ces événements.

Une corrélation n’est pas une preuve.

Mais :

La croissance a commencé immédiatement après que l’intégration X a commencé à créer le hook Y chaque minute.

constitue une piste bien plus solide que :

WooCommerce a peut-être besoin d’optimisation.

Distinguer le producteur d’une défaillance de nettoyage

C’est l’une des distinctions de diagnostic les plus utiles.

Une croissance inattendue concerne généralement l’un de ces rythmes, ou les deux :

rythme de création
Vitesse de création des nouveaux enregistrements.

rythme de retrait
Vitesse à laquelle les anciens enregistrements sont supprimés, expirent, sont archivés ou autrement retirés.

Un modèle utile est :

Rythme de croissance nette ≈ rythme de création − rythme de retrait

Si 1 000 enregistrements sont créés par heure et 1 000 retirés, le jeu de données peut rester stable.

Si la création monte à 20 000 par heure alors que le retrait reste à 1 000, la table grossit.

Si la création reste normale, mais que le retrait s’arrête complètement, la table grossit aussi.

Posez donc les deux questions :

Pourquoi ces enregistrements sont-ils créés ?

et :

Qu’est-ce qui est censé les supprimer ?

Examiner uniquement le nettoyage peut faire manquer un producteur devenu incontrôlé.

Examiner uniquement la création peut faire manquer un processus de conservation défaillant.

Une séquence pratique de diagnostic

Pour une base WooCommerce qui grossit activement, suivez cet ordre.

1. Préserver un état récupérable

   Avant toute opération destructive :

   • confirmez l’existence d’une sauvegarde récente.
   • confirmez qu’elle peut réellement être restaurée.
   • préservez les journaux et la configuration pertinents.
   • relevez les tailles de la base et des tables.

   Si le stockage approche dangereusement de sa limite, un confinement rapide peut être nécessaire. Les éléments de diagnostic restent importants.

2. Établir la pente de croissance

   Effectuez des mesures répétées.

   Identifiez :

   • quelles tables changent
   • à quelle vitesse
   • si la croissance est continue ou par à-coups

3. Identifier la famille de données

   Examinez les enregistrements sans les modifier.

   Recherchez :

   • l’état
   • le hook
   • le préfixe de clé
   • le type d’enregistrement
   • l’horodatage
   • les identifiants propres au composant

4. Identifier le producteur

   Reliez les données :

   • WooCommerce lui-même
   • Action Scheduler
   • une extension
   • au plugin personnalisé
   • une intégration
   • au comportement des robots ou des sessions
   • à l’import
   • aux rapports
   • à la journalisation

5. Identifier le cycle de vie prévu

   Déterminez :

   • pourquoi les données existent
   • si elles doivent expirer
   • comment le nettoyage doit se dérouler
   • si le mécanisme de nettoyage s’exécute

6. Déterminer la valeur métier

   Classez les enregistrements.

   Nécessaires aux opérations

   Commandes, états de paiement, références d’exécution, paniers actifs, abonnements ou autres enregistrements métier actifs.

   Historiques, mais précieux

   Traces d’audit, historique opérationnel terminé, données de rapports ou enregistrements nécessaires à la comptabilité ou aux exigences de conformité.

   Régénérables

   Index, caches et données de recherche dérivées pouvant être reconstruits sans risque par un processus vérifié.

   Supprimables après vérification

   États temporaires expirés, anciennes données de débogage ou artefacts d’échec dont la finalité métier est terminée.

   La classification précède la suppression.

7. Arrêter ou contenir la production anormale de données

   Si un composant produit un volume clairement anormal, corrigez ou contenez temporairement ce parcours lorsque cela est opérationnellement sûr.

   Ne nettoyez pas des millions de lignes tout en laissant un producteur en écrire des millions d’autres.

8. Nettoyer de manière contrôlée

   Seulement après avoir compris la sémantique des données.

   Pour les grands jeux de données :

   • utilisez une sauvegarde récente.
   • testez la condition de suppression.
   • privilégiez les mécanismes applicatifs ou CLI pris en charge lorsqu’ils conviennent.
   • envisagez un traitement par lots.
   • évitez les périodes de pointe commerciale.
   • surveillez la charge de la base et du serveur.
   • vérifiez ensuite le parcours applicatif concerné.

9. Mesurer à nouveau

   La question essentielle n’est pas :

   La base est-elle plus petite ?

   Concrètement :

   La croissance anormale a-t-elle cessé ?

Pourquoi le nettoyage seul échoue souvent

Supposons qu’une table de 3 GB soit réduite à 200 MB.

Cela semble être un succès.

Vingt-quatre heures plus tard, elle fait à nouveau 700 MB.

Le nettoyage a fonctionné.

L’incident n’a pas été résolu.

Le producteur n’a jamais été corrigé.

C’est pourquoi réduire la taille ne doit pas être le critère principal de vérification d’une base qui grossit activement.

La véritable preuve est :

rythme de croissance avant correction → rythme de croissance après correction

avec la vérification que le parcours commercial concerné continue de fonctionner correctement.

Ne pas supprimer directement des données parce qu’un résultat de recherche affirme que la table peut être nettoyée

Les bases WooCommerce contiennent souvent des relations critiques pour l’activité qui ne sont pas visibles en regardant une ligne dans phpMyAdmin.

Une table dont le nom contient les mots :

cache

session

log

temporary

scheduled

ne signifie pas automatiquement que chaque ligne est supprimable.

Le contexte compte.

Un cas réel en production : préserver les données nécessaires, retirer la croissance incontrôlée

Rétablir une base ne consiste souvent pas à supprimer tout ce qui est ancien.

Cette étude de cas DevFluxr sur l’architecture des données WooCommerce documente un système WooCommerce en production où un important ensemble de données de localisation, des contenus générés, des relations, l’indexation et la croissance ont dû être traités comme un cycle de vie unique.

La décision d’ingénierie importante consistait à séparer les enregistrements opérationnels nécessaires de la croissance supprimable, plutôt qu’à reconstruire ou supprimer les données sans discernement.

La hiérarchie et le parcours métier nécessaires ont été conservés, tandis que le poids de la base a été sensiblement réduit.

Le même principe s’applique aux incidents de croissance :

Protéger d’abord l’état métier. Retirer ensuite seulement ce que les éléments disponibles montrent comme inutile.

Éviter le retour du problème

Une base WooCommerce ne devrait pas nécessiter des nettoyages manuels constants pour rester opérationnelle.

Pour les extensions et parcours producteurs de données, définissez :

• le responsable
• le volume attendu
• la conservation
• le mécanisme de nettoyage
• le comportement en cas d’échec
• l’observabilité

Pour les boutiques importantes, surveillez au moins :

• la taille totale de la base
• les plus fortes variations des tables
• les tendances Pending/Failed d’Action Scheduler
• la croissance anormale des sessions
• le volume d’erreurs et de journaux
• la marge d’espace disque
• la durée et les échecs des sauvegardes
• les intégrations majeures productrices de données

Une plateforme d’observabilité d’entreprise n’est pas nécessaire pour constater qu’une table grossit beaucoup plus vite que la normale.

Un instantané périodique peut déjà apporter des éléments précieux.

L’alerte précoce utile est :

le schéma de croissance de cette table a changé

avant que l’hébergeur n’annonce :

votre base a atteint sa limite.

Quand faire appel à une expertise spécialisée

Une investigation spécialisée est justifiée lorsque :

• la base grossit chaque jour sans producteur identifié.
• la taille approche des limites d’hébergement ou de stockage.
• Action Scheduler contient des centaines de milliers ou des millions d’enregistrements inattendus.
• le nettoyage réduit temporairement la taille, mais la croissance revient vite.
• wp_options ou une table propre à un plugin se développe rapidement.
• les sessions WooCommerce actives semblent anormales.
• les opérations de base affectent le tunnel de commande, l’administration ou les tâches de fond.
• une migration ou synchronisation HPOS est impliquée.
• une intégration ou un plugin personnalisé possède les données qui grossissent.
• des nettoyages antérieurs ont supprimé des enregistrements sans expliquer leur source.
• les données de production ne peuvent pas être classées sans risque comme supprimables.

L’objectif ne doit alors pas être :

réduire la base.

Il doit être de :

identifier le producteur, comprendre le cycle de vie, arrêter la création anormale, préserver l’état métier nécessaire, retirer seulement les données vérifiées comme supprimables et démontrer le retour à une croissance normale.

DevFluxr intervient sur les problèmes WooCommerce de base de données, traitements de fond, performances et remise en service lorsque nettoyer aveuglément créerait un risque inacceptable.