磁盘满导致MySQL启动失败时，须先腾出至少1GB空间，再清理binlog（用PURGE BINARY LOGS）和tmpdir下残留临时文件，最后检查innodb_log_file_size、刷盘状态及max_binlog_size等关键配置。
磁盘满了 MySQL 直接挂了，重启失败怎么办
先确认是不是 mysqld 进程根本起不来，且错误日志里反复出现 OS error code 28: No space left on device 或 Cannot write to log file。这不是配置问题，是物理空间耗尽导致的硬性阻断——必须先腾出至少 1GB 空间，MySQL 才可能启动。别急着删库或改配置，优先清理两类文件：binlog 和 tmpdir 下的残留临时文件。
如何安全清理 binlog 文件而不破坏主从或恢复能力
直接 rm -f 删除 mysql-bin.* 文件会破坏二进制日志链，可能导致主从同步断裂、POINT IN TIME 恢复失效。正确做法是让 MySQL 自己管理生命周期：
- 查当前正在用的 binlog：
SHOW MASTER STATUS;，记下File字段值（如mysql-bin.000123） - 确认没有从库在拉取更老的日志：
SHOW SLAVE HOSTS;+ 查各从库的Relay_Master_Log_File - 执行清理：例如保留最近 7 天，运行
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY); - 或按文件名清理（更稳妥）：
PURGE BINARY LOGS TO 'mysql-bin.000120';，确保目标文件名比SHOW MASTER STATUS返回的File更旧
注意：expire_logs_days 是被动策略，磁盘已满时它不会立刻生效；必须手动 PURGE 才能释放空间。
tmpdir 里的临时文件怎么定位和清除
MySQL 在排序、大结果集、临时表等场景会把中间数据写入 tmpdir，崩溃后这些文件常被遗留。默认路径通常是 /tmp 或 /var/tmp，但以实际配置为准：
- 查真实路径：
SELECT @@tmpdir; - 进对应目录，筛选大而旧的文件：
find /tmp -name "ibtmp*" -o -name "#sql_*" -o -name "mysqltmp*" -size +100M -mtime +1 - 确认进程没在用：
lsof +D /tmp | grep mysqld，若无输出，可安全删除匹配项 - 避免下次再爆：
tmpdir不要设在根分区，建议单独挂载小容量 SSD 分区，或改到/dev/shm（内存文件系统，需控制查询复杂度）
重启后必须立刻检查的三件事
空间腾出来、MySQL 起来了，不代表万事大吉。以下检查漏掉任一，可能几天后又崩：
- 确认
innodb_log_file_size× 2 不超过可用磁盘空间的 25%，否则 crash recovery 可能失败 - 运行
SHOW ENGINE INNODB STATUS\G，重点看LOG小节里Log sequence number和Last checkpoint at是否接近，差太多说明刷盘滞后 - 检查
max_binlog_size是否过大（如 1GB），建议设为 100–256MB，避免单个 binlog 文件撑爆分区
最易被忽略的是：tmpdir 权限错乱或 SELinux 上下文损坏，会导致 MySQL 启动后仍无法写临时文件——哪怕磁盘有空余，也会静默降级到 /var/lib/mysql 下创建临时文件，最终再次填满数据目录。
