如何解决MySQL因磁盘空间满导致无法启动的问题

MySQL因磁盘满无法启动的核心矛盾是系统级写入拒绝（Error 28），需先精准定位满载分区（df -h）、确认datadir/tmpdir实际路径，再分类清理：可截断slow_log/error_log；binlog须用PURGE命令；ibtmp1需停库后删除；重启前检查error.log末行及lsof +L1残留文件，并确保tmpdir权限正确。

MySQL 因磁盘空间满无法启动，**核心矛盾不是“服务坏了”，而是写入被系统拒绝（Error number 28）——所有初始化动作（如刷 redo、加载表空间、写错误日志）都会失败。必须先释放空间，且不能破坏 MySQL 文件系统一致性。

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

别猜 /var/lib/mysql，实际可能是 /tmp、/var/log 或根分区其他位置。直接运行：

• df -h 看所有挂载点使用率，重点关注 Use% ≥95% 的那一行
• mysqladmin -u root -p ping 测试基础连通性；如果失败，说明已卡在系统层，跳过 SQL 操作
• 查 MySQL 实际数据目录：mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"，确认它挂在哪块盘上
• 查临时目录：mysql -u root -p -e "SHOW VARIABLES LIKE 'tmpdir';"，/tmp 是 tmpfs 内存盘时满也会阻塞

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

误删会直接导致 MySQL 启动报错或跳过 binlog，甚至无法识别表结构。区分清楚再动手：

• 可安全清空（不需停库）：slow_query_log_file 和 log_error 对应的文件，用 echo "" > /path/to/file.log 截断即可
• 必须进 MySQL 才能删：mysql-bin.* 日志，必须用 PURGE BINARY LOGS BEFORE '2026-06-01 00:00:00'; 或 PURGE BINARY LOGS TO 'mysql-bin.000200';，不能 rm
• 需停库后处理：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 在异常退出后滞留。这两类问题清理空间后仍无法启动，必须针对性处理，不能靠“重启试试”。