磁盘空间满导致MySQL无法启动的修复方法

先说个很实际的问题：MySQL 起不来了，错误日志里赫然写着 Error number 28。别慌，这本质上不是 MySQL 自己出了什么惊天大病，而是操作系统跟它翻脸了——磁盘写不进去了。所有启动动作，不管是刷 redo log、加载表空间还是记一条错误日志，统统被系统拒绝。所以，解决问题的路径很清晰：先释放空间，但绝不能乱动 MySQL 的文件体系结构。

先确认到底是哪个路径塞爆了

别一上来就盯着 /var/lib/mysql 揍，它未必是真凶——/tmp、/var/log 甚至根分区都可能才是拖死 MySQL 的元凶。直接跑几个命令就清楚了：

• df -h：看所有挂载点的使用率，重点关注那些 Use% ≥95% 的行，那才是真正的瓶颈。
• mysqladmin -u root -p ping：测试基础连通性。如果这条命令都失败了，说明 MySQL 已经卡在了系统层，SQL 级操作就不用想了。
• 查 MySQL 实际数据目录：用 mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"，确认它落在哪块盘上。另外一个是 tmpdir，别忽略了临时目录：SHOW VARIABLES LIKE 'tmpdir';——如果 /tmp 是个 tmpfs 内存盘，它满了也能把 MySQL 卡死。

哪些文件能立刻删，哪些必须进 MySQL 才能动

千万注意：误删的动作如果姿势不对，MySQL 可能启动报错甚至直接跳过 binlog，后果更麻烦。动手前，先给文件分个类：

• 安全清空，无需停库：对应 slow_query_log_file 和 log_error 的文件路径，直接用 echo "" > /path/to/file.log 截断就行，不心疼。
• 必须进 MySQL 才能删：mysql-bin.* 日志文件。千万不能 rm 暴力删除，得用 PURGE BINARY LOGS BEFORE '2026-06-01 00:00:00'; 或 PURGE BINARY LOGS TO 'mysql-bin.000200'; 来安全地清理。
• 需停库后处理：ib_logfile0、ib_logfile1（即 redo log）。删除它们的前提是，先设好 innodb_fast_shutdown = 0 再正常关闭 mysqld，否则数据库完整性可能出问题。
• 常被忽略的“隐形冲击波”：ibtmp1。即使 MySQL 已经 stop，它也可能还占着几十 GB 不自动释放。停库后直接 rm /var/lib/mysql/ibtmp1 就是了，干净利落。

清理后 MySQL 还起不来？重点检查这三处

空间释放了不等于自动恢复。MySQL 启动时，残留状态照样能把你拦在门外：

• 检查 /var/log/mysql/error.log 最末几行，如果还有 No space left on device 的报错，说明还有隐藏的大文件没清理干净。用 lsof -p $(pgrep mysqld) | grep deleted 来找出那些已经被删除、但进程仍占着空间的文件。
• 如果看到 InnoDB: Unable to lock ./ibdata1 或者类似提示，那多半是 ibdata1 膨胀了，并且 innodb_file_per_table = OFF 的情况下，删表也不缩文件大小。这种情况只有导出重建一途。
• 重启前务必确认 tmpdir 目录权限正确：chown mysql:mysql /tmp（如果 tmpdir 就是 /tmp），否则启动时创建临时文件失败，又是一次崩溃。

要我说，真正棘手的从来不是 binlog 塞满——那是小儿科。真正的硬骨头是 ibdata1 在共享表空间模式下只增不减，或者是 ibtmp1 在异常退出后滞留浪费空间。这两类问题，清理空间后仍然无法启动，必须针对性地处理，不能指望“重启试试”能蒙混过关。