磁盘空间或inodes耗尽是mysqld静默退出的高频原因；需并行执行df -h和df -i检查datadir及pid-file路径，inodes 100%时优先清理小文件如旧.err日志和过期binlog。
直接说结论：这个报错本身不说明磁盘问题，但磁盘空间或 inodes 耗尽是导致 mysqld 静默退出的高频原因——它根本来不及写日志、更不会更新 pid-file，只留下这句兜底提示。
为什么 df -h 看着还有空间，MySQL 却起不来
常见错觉是“df -h 显示剩余 10%，肯定够用”，但 MySQL 启动时要写 ib_logfile、buffer pool 初始化页、错误日志头、甚至临时表空间。这些操作对磁盘空间和 inodes 都敏感：
- 若
df -i显示 inodes 使用率 100%，哪怕df -h还剩 20GB，mysqld 也会在 open() 第一个文件时失败，直接退出 - 小文件爆满（如残留的
*.err、binlog、innodb_temp）是 inodes 耗尽主因，不是大文件占满空间 - tmpfs 挂载点（如
/var/run/mysqld）空间独立于磁盘，df -h /var/run才能看它是否满
必须并行检查的两个命令
不要只跑一个 df -h 就下结论。以下两条命令缺一不可，且要针对你的 datadir 和 pid-file 所在路径分别执行：
-
df -h /var/lib/mysql（或你实际的datadir路径）→ 看 Block 使用率 -
df -i /var/lib/mysql（同上路径）→ 看 inodes 使用率；只要 Use% 是 100，就必须清理
注意：pid-file 若设在 /var/run/mysqld/，还得额外跑 df -h /var/run 和 df -i /var/run。
清理 inodes 的实操优先级
inodes 100% 时，删大文件没用，必须删小文件。按以下顺序快速定位：
- 查最老的
.err日志：find /var/lib/mysql -name "*.err" -type f | head -n 5，确认是否可删；过期的（如 >7 天）直接find /var/lib/mysql -name "*.err" -mtime +7 -delete - 查 binlog 清理窗口：
mysql -u root -e "SHOW BINARY LOGS;"，再用PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00';安全清理 - 别碰
ib_logfile*或ibdata1：它们不是 inodes 杀手，乱删会导致 InnoDB 启动失败
磁盘 IO 卡住也会表现为“没写 PID”
尤其在宝塔、低配云服务器或机械盘上，mysqld 启动时同步刷 buffer pool、校验表空间，若磁盘响应卡顿（iostat -x 1 3 中 %util >90% 或 await >50ms），进程会卡死在 write pid-file 前——现象完全一样，但日志可能为空或只有时间戳。
此时不要删文件，先停掉非关键定时任务（如宝塔备份、日志压缩），再观察 iostat 输出是否回落。强行 drop_caches 反而加剧 IO 波动，对启动无帮助。
真正麻烦的是权限、配置、inodes、IO 四者叠加：比如 datadir 权限不对 + inodes 耗尽 + tmpfs 空间不足，错误日志又恰好被重定向到满 inodes 的路径——这种组合会让 tail -n 100 看不到任何线索。务必把 df -h 和 df -i 当成启动前必检动作，而不是出错后才想起来跑。
