Je reçois un mail d'OVH m'annonçant que la base de donnée d'un de mes hébergements dépasse les 80%.

Je vais voir sur mon espace client, et effectivement, cela a l'air bien plein tout ça…

Voici les solutions proposées par OVH

Nous vous rappelons, qu'en cas de dépassement du quota maximal alloué, votre base de données n'est plus accessible qu'en lecture seule.
Cela signifie que modifications et enregistrements ne seront plus possibles.

Plusieurs solutions existent afin de prévenir cette situation :

– Souscrivez à une offre d'hébergement dont le quota est plus élevé (voir nos offres : https://www.ovh.com//fr/hebergement-web)
Pour cela, rendez-vous dans votre Espace Client OVH.com, cliquez sur votre hébergement dans « Plateformes », puis sur l'option « Changer d'offre ».
Guide : https://docs.ovh.com/pages/releaseview.action?pageId=18121012

– Commandez une option SQL disposant d'un quota supérieur https://www.ovh.com//fr/hebergement-web/options-sql.xml
Plus de détails : https://docs.ovh.com/display/public/CRHW/Produits+et+offres+BDD

РEffectuez l'optimisation des tables de votre base de donn̩es
Guide : https://docs.ovh.com/pages/releaseview.action?pageId=12225434

РSupprimez les donn̩es inutiles (effectuez une sauvegarde avant toute suppression)
Guide : https://docs.ovh.com/pages/releaseview.action?pageId=12225507

Avant de sortir la CB pour upgrader l'offre d'hébergement ou commander une option SQL, essayons les deux dernières solutions.

Attention, vous devez avoir les connaissances nécessaires en MySQL et effectuer au préalable une sauvegarde de votre base de données.

Direction phpMyAdmin… Effectivement, mes 146 tables occupent 174,8 Mo.

Optimiser les tables

Dans la dernière colonne du total, phpMyAdmin affiche le volume occupé par les données perdues : 5,5 Mo

Cocher les tables avec perte et sélectionnez Optimiser.

Après optimisation, la base de données n'occupe plus que 166,4 Mo.

Pas mal, mais comme on a des sites sous WordPress, on doit pouvoir faire mieux.

Faire de la place

Je classe ma liste de table par ordre décroissant de volume. Les grosses tables sont, sans surprise, celles qui se terminent par _posts. C'est à dire celles des blogs WordPress qui stockent les articles (et autres contenus) de mes blogs. Pourquoi un si gros volume ? Parce que WordPress crée une copie de sauvegarde automatique à chaque fois que vous modifiez un article. Ces sauvegardes portent le post_type ‘revisions'.

Voici la requête  SQL pour un blog WordPress pour lequel vous auriez conservé le profixe de table wp_ (ce qui n'est pas conseillé). Adaptez à votre préfixe de tables. Et surtout, relisez-vous bien avant d'exécuter. C'est une requête DELETE tout de même !

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

et après, encore une petite optimisation

OPTIMIZE TABLE 'wp_posts';

Après purge de la plus grosse des tables de blog, la base ne fait plus que 144,8 Mo. Après purge de la 2e plus grosse, on est passés à 83,1 Mo.

Par contre, pas de panique, votre espace client OVH va continuer à afficher l'ancien volume. Il faudra patienter le temps que ça se rafraîchisse…