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 在异常退出后滞留。这两类问题清理空间后仍无法启动，必须针对性处理，不能靠“重启试试”。
