最常见原因是 mysqld 进程无权限在 pid-file 指定路径创建或写入文件，常伴日志、数据目录不可写；需检查并修复父目录属主（mysql）与写权限，注意 tmpfs 路径需 systemd runtimedirectory 配置；同时排查磁盘空间或 inodes 耗尽导致静默退出。
权限不足导致 mysqld 无法写入 PID 文件
这个错误最常见原因就是 mysqld 进程没有权限在指定路径创建或写入 mysqld.pid。它不只影响 PID 文件，往往也意味着日志目录、数据目录同样不可写。
先确认 PID 文件路径：查看 /etc/my.cnf 中 [mysqld] 段的 pid-file 配置（如未设置，默认用 datadir 下的 mysqld.pid）；再检查该路径父目录是否属于 mysql 用户且可写：
- 执行
ls -ld /var/run/mysqld或ls -ld /usr/local/mysql/data，确认输出中 owner 是mysql，且有w权限 - 若不是，运行
chown -R mysql:mysql /var/run/mysqld和chmod -R 755 /var/run/mysqld（注意：不要用777，MySQL 8.0+ 会拒绝启动） - 特别注意
/var/run/mysqld是临时文件系统（tmpfs），重启后消失，建议在 systemd service 文件中加RuntimeDirectory=mysqld自动重建
磁盘空间或 inodes 耗尽触发静默退出
MySQL 启动时若发现数据目录所在分区 df -h 满了，或 df -i 显示 inodes 100% 使用，mysqld 会直接退出，不写日志也不更新 PID 文件——现象就是纯报错无上下文。
快速验证步骤：
- 运行
df -h /var/lib/mysql（或你的datadir所在挂载点），确认使用率 - 运行
df -i /var/lib/mysql，如果Use%列是100%，说明小文件爆满（比如残留的binlog、innodb_temp或大量.err日志） - 清理方向：
find /var/lib/mysql -name "*.err" -mtime +7 -delete，或删旧 binlog：mysql -u root -e "PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00';"
配置与实际路径不一致引发权限误判
你以为改了 datadir，但 mysqld 根本没读到它——结果它仍尝试往默认路径（如 /usr/local/mysql/data）写 PID，而那个路径根本不存在或权限不对。
必须验证配置是否生效：
- 用
mysqld --no-defaults --verbose --help | grep "Default options"看它实际加载哪些配置文件 - 用
mysqld --no-defaults --validate-config --basedir=/usr/local/mysql --datadir=/var/lib/mysql做语法和路径校验（MySQL 5.7+ 支持） - 如果
systemctl启动失败，检查systemctl show mysql | grep Environment，确认没被环境变量覆盖MYSQL_HOME或MY_CNF
SELinux 或 AppArmor 拦截写操作（仅限 CentOS/RHEL/Ubuntu）
即使权限看起来完全正确，SELinux 也可能阻止 mysqld 写 PID 文件。典型表现是：chown 和 chmod 全部成功，但启动仍失败，且 /var/log/audit/audit.log 里有 avc: denied 记录。
临时诊断与绕过：
- 运行
setenforce 0关 SELinux，再试启动；若成功，说明是它拦的 - 永久修复不要直接关 SELinux，而是用
semanage fcontext -a -t mysqld_var_run_t "/var/run/mysqld(/.*)?"+restorecon -Rv /var/run/mysqld - Ubuntu 用户查
aa-status，若有mysqldprofile 被 enforce，需调整/etc/apparmor.d/usr.sbin.mysqld中的路径规则
真正卡住的地方往往不是单一问题：比如你修了权限，但磁盘 inode 满了，或者关了 SELinux 却忘了清空旧 mysql-bin.index，它会立刻让进程崩溃。动手前一定先看 journalctl -u mysql -n 50 -e 或配置好的 error log 路径，别只盯着 PID 文件本身。
