根本原因是mysqld进程在写PID文件前已崩溃，需优先查看真实错误日志（如/var/log/mysqld.log末尾）、检查磁盘空间/inodes、/var/run/mysqld目录权限及SELinux策略，而非直接操作PID文件。
MySQL在CentOS 8上启动失败并报 The server quit without updating PID file，根本不是PID文件本身的问题，而是mysqld进程在写入它之前就崩溃退出了。必须先看日志、再查权限、最后动配置。
怎么看真实错误日志而不是猜PID问题
这个错误是“兜底提示”，不是根因。直接删 mysqld.pid 或 touch 它只会掩盖问题。
- 先确认日志路径：
mysqld --no-defaults --verbose --help | grep "log-error"，默认通常是/var/log/mysqld.log或/var/lib/mysql/$(hostname).err - 重点看日志末尾 3–5 行，尤其是带
innodb:、Operating system error number、Can't create IP socket的行 - 如果日志为空或根本不存在，说明 mysqld 连日志文件都打不开——大概率是
log-error配置路径的父目录不存在，或权限不对（比如属主不是mysql）
为什么 /var/run/mysqld 目录总“消失”
CentOS 8 默认用 systemd，/var/run 是 tmpfs，重启后整个目录清空。但 MySQL 启动时会尝试往 pid-file 所在目录写文件，若该目录不存在或不可写，就会静默退出。
- 查配置里
pid-file路径：mysqld --no-defaults --verbose --help | grep "pid-file"，常见值是/var/run/mysqld/mysqld.pid - 手动创建并授权：
mkdir -p /var/run/mysqld→chown mysql:mysql /var/run/mysqld→chmod 755 /var/run/mysqld - 但重启后失效：需让 systemd 持久化这个目录，编辑
/usr/lib/systemd/system/mysqld.service，在[Service]段加一行：RuntimeDirectory=mysqld
磁盘空间和 inodes 耗尽也会触发这个报错
哪怕目录存在、权限正确，只要所在分区满，mysqld 就无法写任何文件，包括 PID 和日志，且错误信息极其模糊。
- 检查
/run（即/var/run所在挂载点）空间：df -h /run。tmpfs 默认只给几十 MB，很容易爆满 - 检查 inodes：
df -i /run。如果 Use% 是 100%，说明小文件（如残留 .err、.pid、socket）占满了 inode，find /run/mysqld -type f -delete可清理 - 同时检查数据目录挂载点：
df -h /var/lib/mysql和df -i /var/lib/mysql，≥95% 使用率必须处理
SELinux 干预时连日志都不让你写
CentOS 8 默认启用 SELinux，它可能阻止 mysqld 创建 pid-file 或写日志，而错误日志里不会明说，只显示 I/O 失败。
- 临时验证是否是 SELinux 导致：
setenforce 0，再试systemctl start mysqld。如果成功，就是它 - 永久修复（推荐）：
semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"→restorecon -Rv /var/lib/mysql - 同时为 pid-file 路径加策略：
semanage fcontext -a -t mysqld_var_run_t "/var/run/mysqld(/.*)?"→restorecon -Rv /var/run/mysqld
真正容易被忽略的是：错误日志里常混着多个报错，但只有第一个才是根因。比如 error number 28（No space left on device）触发后，后续所有 Permission denied、Can't open data directory 都是连锁反应——别一看到权限报错就急着改 chmod。
