首页 > 数据库 >MySQL磁盘空间满无法启动修复方法

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

来源：互联网 2026-07-11 08:38:11

MySQL因磁盘空间满无法启动（错误号28）。先用df-h定位满的分区，检查数据目录和临时目录。安全清理：截断慢查询日志和错误日志，用PURGE清理binlog，停库后删除redolog及ibtmp1。若仍无法启动，检查隐藏占用文件、ibdata1膨胀及tmpdir权限。

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

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），否则启动时创建临时文件失败，又是一次崩溃。