Passer au contenu 
Je montre concrètement comment Réduire la taille de la base de données, Vous pouvez ainsi créer des sites Web plus rapidement et sans perdre de contenu : des solutions rapides de plug-ins aux étapes MySQL contrôlées. Ainsi, vous réduisez Temps de chargement, Les utilisateurs peuvent ainsi réduire la charge de travail du serveur et garder un contrôle total sur chaque modification.
Points centraux
Avant de travailler sur les tableaux, je clarifie les objectifs, je sécurise la base de données et je décide quelles étapes de nettoyage sont vraiment nécessaires. J'évite ainsi les risques, j'allège la maintenance et j'obtiens des effets mesurables. Les points suivants vous guident de manière ciblée à travers le processus. Vous recevez un ordre clair, des conseils pratiques et des indications sur les écueils typiques. Vous mettrez ensuite en œuvre des optimisations de manière sûre et reproductible.
- Sauvegarde d'abord : sauvegarde complète et test de relecture
- Plugins utiliser le logiciel : WP-Optimize, WP-Sweep, Advanced Database Cleaner
- phpMyAdminoptimiser les tableaux, nettoyer les transitoires
- wp_options en vue : Vérifier l'autoload et les charges héritées du passé
- Automatiser: Nettoyage régulier et jobs de monitoring
Je priorise les mesures en fonction de l'impact et du risque, je commence par des candidats à la suppression sûrs et j'avance vers des interventions plus profondes. Ainsi, la site web accessible, les données restent intactes et la base de données est allégée de manière planifiable.
Pourquoi les bases de données WordPress croissent - et ce qui compte vraiment
Dans les affaires courantes, on accumule rapidement Révisions, Les commentaires de spam, les contenus supprimés dans la corbeille et les transients expirés sont affichés. De telles entrées augmentent les temps d'interrogation, gonflent les tableaux et augmentent la charge de travail. CPU-consommation de ressources. Sont particulièrement concernés wp_posts (révisions), wp_postmeta (meta-ballast), wp_options (transients, autoload) et wp_comments (spam, corbeille). A cela s'ajoute le surplus dans les tables MySQL, qui survient après de nombreuses suppressions et freine les requêtes. En s'attaquant très tôt à la croissance, on économise des ressources, on réduit le time-to-first-byte et on obtient des données propres.
Diagnostic exact : qu'est-ce qui pousse vraiment ?
Avant de supprimer, je mesure. Dans phpMyAdmin, j'affiche la taille des données et des index par tableau et j'identifie les plus gros consommateurs. Si je veux être plus précis, j'utilise un aperçu via INFORMATION_SCHEMA et je trie par données totales :
SELECT
nom_table,
ROUND((data_length + index_length)/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC ;
Cela me permet de savoir si, par exemple. wp_postmeta en raison de nombreuses métadonnées de produits ou de référencement. Important : la taille physique des fichiers ne diminue pas toujours immédiatement avec InnoDB ; OPTIMIZE TABLE libère de la mémoire au sein de la table et - dans le cas de file_per_table - également au niveau du système de fichiers. Je documente les valeurs de départ et d'arrivée afin de rendre visible le bénéfice de chaque mesure.
Sauvegarder d'abord : comment sécuriser mes données
Avant de supprimer quelque chose, j'exporte la Base de données et je teste la retranscription. Dans phpMyAdmin, je sélectionne la base de données, je clique sur Export et je garde le fichier SQL en local. En outre, un plugin de sauvegarde éprouvé peut créer une deuxième sauvegarde. Je vérifie toujours si la sauvegarde comprend toutes les tables et tous les préfixes, surtout dans le cas de sites multiples ou de sites modifiés. Préfixes des tableaux. Ce n'est que lorsque la sauvegarde et la restauration fonctionnent que je commence le nettoyage.
Staging, rollback et minimisation des temps d'arrêt
Je planifie les interventions de manière à ce que le site reste accessible. Pour cela, je travaille - si possible - d'abord dans une Instance de staging, Je teste les principaux flux (login, checkout, recherche) et ne transfère qu'ensuite les étapes dans le système en direct. Je planifie les suppressions importantes en dehors des heures de visite principales, je désactive la mise en cache juste avant l'exécution, je la vide après l'exécution et je vérifie le journal des erreurs. Pour le rollback, je tiens à disposition une sauvegarde de la base de données testée et je note chaque requête dans un changelog afin de pouvoir annuler les modifications.
Plugins pour wordpress database cleanup au quotidien
Pour les tâches de routine, je mise d'abord sur WP-Optimize, Il traite les révisions, le spam, la corbeille, les transitoires et les tableaux en une seule fois. Après l'installation, j'active le nettoyage automatique et je planifie des exécutions hebdomadaires. Si nécessaire, j'utilise WP-Sweep pour les pingbacks/trackbacks et Advanced Database Cleaner pour les fichiers orphelins. Entrées de manière ciblée. Avant la suppression, je vérifie l'aperçu, désactive les options risquées et ne confirme que les candidats clairs. J'obtiens ainsi des effets sensibles avec un minimum d'efforts et je peux automatiser proprement la routine „wp optimize database“.
Optimisation manuelle dans phpMyAdmin : garder le contrôle
Si j'ai besoin de plus de contrôle, je passe en phpMyAdmin et je trie les tableaux par taille. J'optimise les grands candidats via la liste déroulante, qui contient en interne la commande OPTIMIZE TABLE et réduit les débordements. J'élimine les transitoires expirés avec DELETE FROM wp_options WHERE nom_option LIKE '_transient_%' OR nom_option LIKE '_site_transient_%;. Je supprime les tags non utilisés avec DELETE FROM wp_terms WHERE term_id NOT IN (SELECT term_id FROM wp_term_taxonomy) ;. Après chaque étape, je vérifie le site web et le journal des erreurs avant de poursuivre le nettoyage, afin que Risques rester petit.
Nettoyer les révisions, le spam et la corbeille en toute sécurité
Les révisions peuvent être utiles, mais indéfiniment elles gonflent wp_posts sur . Je les limite avec define('WP_POST_REVISIONS', 3) ; dans le fichier wp-config.php et je supprime les anciennes révisions via un plugin. Je nettoie régulièrement le spam et la corbeille ; cela réduit la taille de wp_comments de manière perceptible. J'examine également les brouillons automatiques et supprime les doublons. Après chaque suppression, je procède à une nouvelle optimisation des tableaux afin de libérer réellement de la mémoire.
Garder wp_options propres : Autoload et Transients
Le tableau wp_options provoque souvent des retards cachés, en particulier à cause de grandes valeurs d'autoload. Je mesure la somme totale des options autoloadées et j'arrête les entrées surdimensionnées qui sont chargées à chaque appel. Je supprime régulièrement les transients expirés, car ils occupent sinon de la place et prolongent les temps de démarrage. Ceux qui souhaitent en savoir plus sur le contexte et les sources de charge typiques trouveront des détails sous Comprendre les transitoires. Après le nettoyage, je contrôle le frontend et le backend pour détecter les effets sur les Temps de chargement à vérifier.
Pour une estimation rapide de la charge de l'autoload, une simple requête m'aide : SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes' ;. Je trouve quelques aberrations sur SELECT nom_option, LENGTH(valeur_option) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 20 ;. Je règle les valeurs importantes et rarement utilisées sur autoload = ’no‘ et je veille à ce que le plugin les charge de manière ciblée si nécessaire.
Optimiser les tableaux de manière ciblée : Qu'est-ce qui apporte le plus ?
Au lieu de tout supprimer de manière aléatoire, je me concentre sur les tableaux ayant le plus grand nombre d'utilisateurs. Effet. wp_posts et wp_postmeta fournissent souvent le levier le plus puissant, suivis de wp_options et wp_comments. Ensuite, je fais une comparaison avant/après dans phpMyAdmin pour mesurer les progrès. Cette transparence permet de limiter les risques et de voir où le prochain passage en vaut la peine. L'aperçu suivant classe les résultats typiques et les actions appropriées afin que vous puissiez procéder de manière structurée.
| Tableau | Cause | Lestage typique | Mesure recommandée | Risque |
|---|---|---|---|---|
| wp_posts | Révisions, projets de voiture | Des dizaines de révisions par article | Limiter/supprimer les révisions, optimiser | Faible en cas de sauvegarde |
| wp_postmeta | Anciennes entrées méta | Méta-clés orphelines | Supprimer la méta orpheline, vérifier les index | Moyen, à vérifier au préalable |
| wp_options | Transients, chargement automatique | Données de cache expirées | Supprimer les transitoires, réduire l'autoload | Faible à moyen |
| wp_comments | Spam, corbeille à papier | Sites contaminés et vagues de spam | Effacement en masse, définir des automatismes | Faible |
Cas particulier de WooCommerce et des boutiques à fort trafic
Les boutiques génèrent un nombre d'enregistrements supérieur à la moyenne en wp_postmeta (variations, attributs, métadonnées de commande) et les remplir wp_options avec les sessions et les transients. Je supprime régulièrement les sessions/transitions expirées, je raccourcis la durée de conservation des cartes erronées et je vérifie si le thème ou les plugins stockent des métadonnées de produit inutiles. Je garde les tables de l'action scheduler (par ex. as_actions) petites en nettoyant plus tôt les tâches terminées et en ne relançant pas indéfiniment les tâches qui ont échoué. Après des ventes ou des importations importantes, je planifie un tour supplémentaire. OPTIMIZE TABLE, pour réduire rapidement le surnombre.
Particularités du multisite
Dans les réseaux, le poids se multiplie sur tous les blogs. Je procède site par site, en respectant les préfixes de tableaux autonomes (par ex. wp_2_) et nettoie en outre Transitions à l'échelle du réseau dans _site_transient_*. Pour les tables globales (par ex. wp_users, wp_usermeta), je ne supprime rien en bloc, mais je vérifie les dépendances entre les sites. Je planifie les tâches de nettoyage en dehors des fenêtres de synchronisation ou de migration afin de préserver la cohérence du réseau.
Étapes de réglage avancées dans MySQL WordPress
En cas de fort trafic, je fais attention à InnoDB-paramètres et index. Un buffer pool bien dimensionné et des index judicieux sur les colonnes fréquemment filtrées (par ex. meta_key dans wp_postmeta) accélèrent considérablement les requêtes. La mise en cache des requêtes existe dans les anciennes versions de MySQL, les configurations modernes profitent plutôt d'une bonne mise en cache au niveau de l'application ou de l'objet. En outre, j'évite les entrées d'autoload surdimensionnées qui ralentissent le chargement précoce des pages ; pour plus de détails, voir Options d'autoload. Après chaque réglage, je mesure à nouveau l'effet sur Temps de réponse de vérifier.
Maîtriser les indices : des modèles éprouvés dans la pratique
Je vérifie de manière ciblée si les filtres typiques sont soutenus de manière judicieuse. Pour wp_postmeta les indices ont évolué vers des (post_id) et - selon les requêtes - sur (meta_key, post_id) a fait ses preuves. Sur wp_options il existe par défaut un index sur option_name; pour les requêtes après autoload, j'utilise l'outil existant (autoload)-ou combiner le filtre avec LIMIT. Avant d'ajouter des index, je simule les requêtes les plus fréquentes, je mesure leur durée d'exécution et je garde à l'esprit que les index peuvent consommer de la mémoire et allonger les processus d'écriture. Je supprime les index superflus ou redondants s'ils n'apportent pas d'avantages mesurables.
WP-CLI en pratique : nettoyage rapide et scriptable
Si l'accès au shell est disponible, j'accélère les routines avec WP-CLI. Exemples que j'utilise dans les fenêtres de maintenance :
- Nettoyer les transitoires :
wp transient delete --expiredet, si nécessairewp transient delete --all - Vider le spam/la corbeille à papier :
wp comment delete --status=spam --force,wp comment delete --status=trash --force - Réduire les révisions :
wp post list --post_type='post,page' --field=ID --post_status=publish | xargs -n100 wp post delete-revision - Optimiser la base de données :
wp db optimizeet vérifier les tailles avecwp db size --tables
Ces commandes peuvent être intégrées dans des tâches Cron ou des scripts de déploiement. Je commence par des commandes de lecture (listes, comptage), je confirme la sélection et je n'exécute les commandes de suppression qu'ensuite.
Jeu de caractères, collation et format Row
Des jeux de caractères incohérents augmentent les risques lors des migrations et peuvent limiter les index aux colonnes de texte. Dans la mesure du possible, je mets utf8mb4 avec une collation consistante (par ex. utf8mb4_unicode_ci). Avant une conversion, je sauvegarde la base de données, je vérifie une mise à jour de staging et je convertis les tables par étapes contrôlées. Pour les tables InnoDB, j'utilise un format de rangée actuel (par ex. DYNAMIC), afin que les longs TEXT/VARCHAR puissent être externalisés efficacement. En combinaison avec innodb_file_per_table=ON assure OPTIMIZE TABLE pour que l'espace libre soit renvoyé au système de fichiers.
Automatisation : planifier la propreté au lieu de l'espérer
Je gagne du temps en effectuant des tâches répétitives. terminez. Dans WP-Optimize, je configure des nettoyages hebdomadaires et des optimisations mensuelles des tables. En outre, un Cron système peut déclencher de manière fiable le Cron propre à WordPress afin que les tâches planifiées ne soient pas annulées. Pour les actions répétées telles que „wp optimize database“, je définis des plages horaires fixes en dehors des heures de fréquentation principales. Ainsi, la base de données reste durablement allégée sans que je doive déclencher manuellement chaque étape.
Suivi et tests : rendre le succès visible
Après chaque tour, je contrôle Taille de la BD dans phpMyAdmin et je documente l'évolution. Je contrôle l'évolution du temps de chargement du premier octet et de la plus grande peinture de contenu. J'aborde rapidement les augmentations remarquables de wp_options ou wp_postmeta, avant qu'elles n'affectent les performances. Cet article fournit des pistes de réflexion utiles pour des options durablement propres : Gérer wp_options. En parallèle, je tiens un changelog avec la date, les mesures et le résultat, afin de pouvoir suivre les décisions par la suite.
Chiffres clés et valeurs seuils pour la pratique
Pour que les optimisations ne s'enlisent pas, je définis des valeurs limites claires. Exemples : "Je ne veux pas que l'on m'utilise : Maintenir la somme d'autoload en dessous de 1-2 Mo ; wp_postmeta par rapport à wp_posts plausible (pas de facteurs dépassant 20-50x sans raison valable) ; part des transitoires en wp_options ne pas faire croître. Pour les performances, je mesure régulièrement le TTFB, les requêtes de recherche dans le backend (par ex. liste de produits) et les temps de chargement de l'administrateur. Si des valeurs clés augmentent ou si des tableaux se déplacent soudainement, je lance une analyse ciblée au lieu d'une ronde générale de „tout supprimer“.
Supprimer systématiquement les tables orphelines et les résidus de désinstallation
De nombreux plugins laissent des tableaux et des options. Je répertorie les tableaux non essentiels à l'aide de préfixes, je rassemble les candidats et je procède en deux étapes : D'abord, je renomme le tableau à titre de test (par ex. RENAME TABLE wp_altplugin_data TO wp_altplugin_data_backup ;) et j'observe la page. Si tout reste stable, je supprime définitivement le tableau. Dans wp_options je recherche des espaces de noms de plugins typiques (option_name LIKE '%pluginname%'.) et ne supprime que les entrées dont j'ai compris la fonction. Pour wp_usermeta et wp_postmeta j'identifie les clés orphelines en vérifiant si les identifiants référencés existent encore.
Éviter les erreurs fréquentes
Je ne supprime jamais sans Sauvegarde et le test de retour. Je ne procède à des suppressions en masse risquées de wp_postmeta qu'après avoir analysé les clés méta orphelines. J'utilise les nettoyages de plugins de manière sélective au lieu d'activer chaque option. Après la suppression, je vide les caches et je teste les fonctions afin qu'aucune partie de la page ne tombe en panne de manière inattendue. Si quelque chose n'est pas clair, je travaille d'abord sur une instance de staging et je ne transfère les nettoyages dans le système réel qu'après un test réussi.
Résumé succinct
Avec un ordre clair, propre Sauvegarde et quelques outils permettent d'alléger n'importe quelle base de données WordPress sans perte de données. Je commence par des candidats sûrs comme les transients, les spams et les révisions, j'optimise les tables et je limite la croissance future à l'aide de règles. Pour les configurations plus importantes, je fais appel à des étapes manuelles dans phpMyAdmin et à des points de réglage MySQL judicieux. Les routines automatisées maintiennent la base de données durablement petite et mesurablement rapide. En respectant ces lignes directrices, on réduit la taille, on diminue la charge du serveur et on accélère sensiblement les pages - de manière planifiable, sûre et compréhensible.
