Wenn eine MySQL-Tabelle 52 GB Fragmentierung ansammelt, erzwingt der Festplattenalarm eine schnelle Entscheidung. Die verlockende Abkürzung ist TRUNCATE, aber bei einer Live-Geschäftstabelle bedeutet das sofortigen Datenverlust. Dieser Incident-Bericht zeigt den sichereren Weg: Zuerst die Fragmentierung mit information_schema bestätigen, dann ALTER TABLE ... ENGINE=InnoDB oder pt-online-schema-change verwenden, um die Tabelle ohne Blockierung von Schreibvorgängen neu aufzubauen. Der Autor betont auch, vor jeder Operation Tabellengröße, Zeilenanzahl und Replikationsverzögerung zu prüfen. Für Teams, die MySQL in Produktion betreiben, ist dies ein klassisches Szenario, das ein dokumentiertes Runbook verdient. Die wichtigste Erkenntnis sind nicht die spezifischen Befehle, sondern der Entscheidungsrahmen: TRUNCATE niemals auf einer Tabelle ausführen, die man nicht verlieren kann, immer einen Rollback-Plan haben und den Neuaufbau zuerst auf einer Staging-Kopie testen.
Eine MySQL-Tabelle in Produktion hat 52 GB Fragmentierung angesammelt und einen Festplattenalarm bei 80 % ausgelöst. Der Autor hätte fast TRUNCATE auf einer Live-Tabelle ausgeführt, bevor er das Risiko erkannte. Der Beitrag zeigt sichere Alternativen.