真正原因不是mysqld.pid文件本身，而是pid-file、datadir、log-error三路径权限不一致、inodes耗尽或SELinux/AppArmor拦截，导致mysqld在写入前静默崩溃。
先看错误日志，别删 mysqld.pid
这句报错本身不是真正原因，而是 mysqld 进程在写入 pid-file 前就崩溃了的“结果提示”。直接删 /var/run/mysqld/mysqld.pid 或 touch 它只会掩盖问题，甚至干扰后续诊断。
必须先定位真实退出点：
- 查日志路径：
mysqld --no-defaults --verbose --help | grep "log-error"，常见位置是/var/log/mysqld.log或/var/lib/mysql/$(hostname).err - 重点看日志末尾 3–5 行：含
innodb:、Can't create IP socket、Operating system error number的行最可疑 - 如果日志为空或根本不存在，说明 mysqld 连
log-error路径都打不开——大概率是目录不存在或权限不对
检查 pid-file、datadir、log-error 三者目录权限
MySQL 5.7/8.0 启动时会同时尝试写这三个路径下的文件。任一目录属主不对、无写权限，都会导致静默退出。
操作步骤：
- 确认实际路径：
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权限；若目录不存在，执行：mkdir -p /var/run/mysqld && chown mysql:mysql /var/run/mysqld && chmod 755 /var/run/mysqld - 注意：
/var/run/mysqld是 tmpfs，重启即清空；systemd 用户需在 service 文件中加RuntimeDirectory=mysqld
并行运行 df -h 和 df -i 检查磁盘与 inodes
磁盘空间（block）或 inodes 耗尽，会导致 mysqld 在 open() 第一个文件时失败，不写日志、不更新 pid，只留这句报错。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
关键点：
- 必须对
datadir和pid-file所在路径分别执行：df -h /var/lib/mysql和df -i /var/lib/mysql -
df -i显示Use% = 100时，删大文件无效，必须清理小文件：旧*.err、binlog、innodb_temp - 快速清理：
find /var/lib/mysql -name "*.err" -mtime +7 -delete；或进 MySQL 执行PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00'; -
/var/run/mysqld是独立 tmpfs 分区，需额外跑df -h /var/run和df -i /var/run
验证 SELinux/AppArmor 是否拦截、进程是否残留
SELinux（CentOS/RHEL）或 AppArmor（Ubuntu）可能阻止 mysqld 创建文件或绑定端口，现象就是启动卡在写 pid 前。
排查方式：
- 临时关闭 SELinux：
setenforce 0，再试启动；若恢复则需调整策略，而非永久禁用 - 查是否有残留进程：
ps -ef | grep mysqld，有则kill -9干净后重试 - 检查锁文件：
/var/lock/subsys/mysql若存在且非正常退出遗留，可rm /var/lock/subsys/mysql - 避免误删
ib_logfile*或ibdata1：它们不是 inodes 杀手，乱删会导致 InnoDB 启动失败
真正麻烦的永远不是 mysqld.pid 文件本身，而是它背后那三个路径的权限一致性、磁盘 inodes 状态、以及安全模块的隐形拦截——这些地方一旦出问题，日志可能为空，df -h 看着还有空间，但 mysqld 就是起不来。
