真正失败原因是日志、权限、磁盘或安全策略问题，而非PID文件本身；须先查错误日志路径并分析末几行，再检查pid-file、datadir、log-error三者目录权限、磁盘空间与inodes、配置加载及SELinux/AppArmor限制。
这句报错不是真正原因，只是启动失败后的“甩锅提示”——mysqld进程在写入pid-file前就崩溃退出了，必须查日志、看权限、验磁盘，不能直接删mysqld.pid。
先看真实错误日志在哪、末几行写了啥
日志路径不固定，别硬猜：mysqld --no-defaults --verbose --help | grep "log-error" 才是准的。常见位置有 /var/log/mysqld.log、/var/lib/mysql/$(hostname).err、/usr/local/mysql/data/localhost.err。
重点盯最后 3–5 行，尤其是含这些关键词的行：
-
InnoDB: Cannot allocate memory for the buffer pool→ 内存不足或innodb_buffer_pool_size设太高 -
Can't create IP socket→ 端口被占或bind-address配错 -
Operating system error number 13→ 权限问题（通常是目录属主不是mysql） -
Plugin 'InnoDB' registration as a STORAGE ENGINE failed→ib_logfile*损坏或内存分配失败
如果日志文件为空或根本打不开，说明 mysqld 连日志目录都进不去——大概率是 log-error 路径的父目录权限不对，或目录不存在。
检查 pid-file、datadir、log-error 三者目录权限是否一致
MySQL 启动时要同时写这三个路径：它得能在 pid-file 目录里创建文件，能读写 datadir，还能往 log-error 目录里追加日志。只要其中任一目录属主不是 mysql 或缺写权限，就静默退出。
执行这三步确认：
- 查实际路径：
mysqld --no-defaults --verbose --help | grep -E "(pid-file|datadir|log-error)" - 查每个路径的父目录权限，例如
pid-file = /var/run/mysqld/mysqld.pid→ 运行ls -ld /var/run/mysqld，owner 必须是mysql，且含w权限 - 修复命令（以
/var/run/mysqld为例）：mkdir -p /var/run/mysqld→chown mysql:mysql /var/run/mysqld→chmod 755 /var/run/mysqld
注意：/var/run/mysqld 是 tmpfs，重启即丢。systemd 用户必须在 mysqld.service 里加 RuntimeDirectory=mysqld，否则每次重启后又没目录。
磁盘空间和 inodes 耗尽会静默失败
MySQL 启动时若发现 datadir 所在分区 df -h 满了，或 df -i 显示 inodes 100%，它不会报具体错误，只留一句 “quit without updating PID file”。
必须手动验证：
-
df -h /var/lib/mysql（替换成你的datadir挂载点），使用率超过 90% 就危险 -
df -i /var/lib/mysql，Use% 达到 100% 表示小文件爆满（比如残留的.err、.binlog、innodb_temp） - 清理建议：
find /var/lib/mysql -name "*.err" -mtime +7 -delete，或进 MySQL 执行PURGE BINARY LOGS BEFORE '2026-09-01 00:00:00';
别漏掉 SELinux/AppArmor 和残留锁文件
CentOS/RHEL 默认开 SELinux，Ubuntu/Debian 常用 AppArmor——它们可能拦住 mysqld 访问 datadir 或创建 socket，但错误日志里往往不提，只让进程退出。
快速验证：
- CentOS：
getenforce返回Enforcing就是它；临时关：setenforce 0；永久关需改/etc/selinux/config中SELINUX=disabled - Ubuntu：
aa-status查状态；临时禁用：sudo systemctl stop apparmor
另外两个易忽略点：
-
/var/lock/subsys/mysql是旧 init script 的锁文件，systemd 下已废弃，但若残留会导致启动脚本报错，直接rm /var/lock/subsys/mysql -
mysql-bin.index在datadir下存在时，可能引发启动冲突，尤其重装或迁移后，删掉再试
真正卡住的地方，永远不在 mysqld.pid 文件本身，而在它背后那三个目录的权限一致性、磁盘底层状态、以及安全策略的隐形拦截——日志末行、df -i、getenforce，这三个命令跑完，80% 的 case 就定位清楚了。
