先说个很实际的问题：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 在异常退出后滞留浪费空间。这两类问题，清理空间后仍然无法启动，必须针对性地处理，不能指望“重启试试”能蒙混过关。
