Lorsqu'une table MySQL accumule 52 Go de fragmentation, l'alerte disque force une décision rapide. Le raccourci tentant est TRUNCATE, mais sur une table métier en production, cela signifie une perte de données immédiate. Ce rapport d'incident présente le chemin plus sûr : d'abord confirmer la fragmentation avec information_schema, puis utiliser ALTER TABLE ... ENGINE=InnoDB ou pt-online-schema-change pour reconstruire la table sans bloquer les écritures. L'auteur insiste également sur la vérification de la taille de la table, du nombre de lignes et du retard de réplication avant toute opération. Pour les équipes qui exploitent MySQL en production, c'est un scénario classique qui mérite un runbook documenté. Le point clé n'est pas les commandes spécifiques mais le cadre de décision : ne jamais TRUNCATE une table que l'on ne peut pas se permettre de perdre, toujours avoir un plan de rollback et tester la reconstruction sur une copie de staging d'abord.
Une table MySQL de production a accumulé 52 Go de fragmentation, déclenchant une alerte disque à 80 %. L'auteur a failli utiliser TRUNCATE sur une table en production avant de réaliser le risque. L'article présente des alternatives sûres.