MySQL

Trouver les tables qui font grossir une base MySQL ou MariaDB

Publié en février 2019 2 extraits de code par Rémy Montangé

Fiche écrite en 2019, pour les navigateurs et les versions de l’époque. Vérifiez qu’elle correspond encore à votre environnement avant de l’appliquer.

Une sauvegarde qui passe de 200 Mo à 3 Go, un hébergement qui signale un quota dépassé, une boutique qui ralentit : avant de chercher plus loin, il faut savoir quelle table a grossi. information_schema le dit en une requête.

SQL

SELECT table_name                                              AS `table`,
      ROUND((data_length + index_length) / 1024 / 1024, 1)    AS taille_mo,
      ROUND(data_free / 1024 / 1024, 1)                       AS recuperable_mo,
      table_rows                                              AS lignes_estimees
FROM information_schema.TABLES
WHERE table_schema = 'ma_base'
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Les coupables reviennent toujours. Sur PrestaShop, les tables de statistiques (ps_connections, ps_connections_source, ps_guest, ps_pagenotfound) grossissent sans fin si personne ne les purge. Sur WordPress, c’est wp_options : une extension désinstallée y laisse souvent des options chargées à chaque page, et quelques mégaoctets d’autoload suffisent à ralentir tout le site. table_rows n’est qu’une estimation sur InnoDB : pour un chiffre exact, un COUNT(*) sur la table concernée.

SQL

-- PrestaShop : statistiques de visites de plus d'un an (sauvegarde avant !)
DELETE FROM ps_connections_source WHERE date_add < DATE_SUB(NOW(), INTERVAL 1 YEAR);
DELETE FROM ps_connections        WHERE date_add < DATE_SUB(NOW(), INTERVAL 1 YEAR);
OPTIMIZE TABLE ps_connections, ps_connections_source;

-- WordPress : options chargées à chaque page, les plus lourdes d'abord
SELECT option_name, LENGTH(option_value) AS octets
FROM wp_options
WHERE autoload = 'yes'
ORDER BY octets DESC
LIMIT 20;

Sources

MySQL, la table INFORMATION_SCHEMA TABLES dev.mysql.com

Sources

Autres fiches MySQL