MySQL启动失败主因是pid-file路径不存在或权限不足：需确认配置中pid-file路径，创建缺失目录（如/var/run/mysqld），并执行chown -R mysql:mysql /var/run/mysqld与chmod 755 /var/run/mysqld；同时排查/tmpfs空间、残留PID文件、SELinux/AppArmor拦截等。
pid-file 配置路径不存在或权限不足
MySQL 启动时会尝试在 pid-file 指定路径创建并写入进程 ID，如果该路径的父目录不存在、不可写，或所属用户不是 mysql，就会报 The server quit without updating PID file 或 Can't check PID filepath: No such file or directory。
常见错误现象包括：systemctl start mysqld 显示 FAILED，日志里反复出现 “unable to create pid file” 类提示。
- 先查配置：运行
mysqld --print-defaults | grep pid-file或直接打开/etc/my.cnf（或/etc/mysql/my.cnf），确认[mysqld]下的pid-file值，例如pid-file = /var/run/mysqld/mysqld.pid - 检查路径是否存在：用
ls -ld /var/run/mysqld看目录是否存在；若无，执行mkdir -p /var/run/mysqld - 检查归属与权限：必须是
mysql用户可写，推荐执行chown -R mysql:mysql /var/run/mysqld和chmod 755 /var/run/mysqld（不建议盲目chmod -R 777，有安全风险） - 注意：某些系统（如新版 systemd）会将
/var/run设为 tmpfs，重启后目录消失，需配合tmpfiles.d配置持久化，或改用/run/mysqld并确保服务单元文件中定义了RuntimeDirectory=mysqld
磁盘空间满导致 pid 写入失败
即使目录存在、权限正确，若所在分区（尤其是 /var 或 /run 所在挂载点）已 100% 占用，MySQL 仍无法写入 pid-file，且错误日志可能只显示模糊的 I/O 失败，不提磁盘空间。
典型表现是：手动 touch /var/run/mysqld/test.pid 也报 No space left on device，但 df -h 看根分区还有余量——此时要重点看 df -i（inode 耗尽）和 df -h /run（/run 是独立 tmpfs 分区，大小默认仅几十 MB）。
- 检查实际占用：
df -h和df -i都要看，尤其关注/run、/var/run、/var/lib/mysql所在挂载点 - 清理 tmpfs 中残留文件：
ls -lt /run/mysqld/，删掉旧的.pid、.sock或空目录（注意别删正在用的） - 临时扩容（仅限 tmpfs）：
mount -o remount,size=256M /run（需加到/etc/fstab或 systemd mount unit 才持久） - 避免误判：不要只依赖
du -sh /var/run，它常为空，因 tmpfs 不计入磁盘使用统计
残留进程或锁文件干扰启动
MySQL 认为 pid-file 已存在且对应进程仍在运行，就会拒绝覆盖或启动新实例，报错类似 PID file found, but no matching process 或直接静默退出。
这通常发生在强制断电、kill -9 后未清理，或 systemd 未正确终止服务的情况下。
- 先确认真实状态：
ps -ef | grep mysqld，看是否有残留的mysqld_safe或mysqld进程（注意过滤grep自身） - 检查 pid 文件内容：
cat /var/run/mysqld/mysqld.pid，再用kill -0 $(cat /var/run/mysqld/mysqld.pid)测试进程是否真活着 - 若进程已死但 pid 文件还在，**直接删除该文件**（
rm /var/run/mysqld/mysqld.pid），再启动；不要 touch 新空文件，MySQL 启动时会自动生成 - 注意 ib_logfile0/ib_logfile1：若 MySQL 初始化后首次启动失败，有时是 redo log 文件损坏，可按知识库提示删掉它们（仅限初始化未完成场景），但删前务必确认数据目录无有效数据
SELinux 或 AppArmor 拦截写入
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使目录权限全开，安全模块也可能禁止 mysqld 进程写入指定路径，错误日志里往往只有“Permission denied”，无具体路径线索。
典型触发场景：把 pid-file 改到非默认路径（如 /data/mysql/mysql.pid），但 SELinux 策略未适配。
- 快速验证：
setenforce 0临时禁用 SELinux，再试启动；若成功，说明是策略问题 - 永久修复（推荐）：用
semanage fcontext -a -t mysqld_var_run_t "/data/mysql(/.*)?"+restorecon -Rv /data/mysql（SELinux）；Ubuntu 则编辑/etc/apparmor.d/usr.sbin.mysqld添加对应路径规则 - 不建议长期关闭 SELinux：它不是“惹祸”，而是被绕过时才暴露问题；同理，AppArmor 规则缺失比权限问题更难排查
- 注意：
chown和chmod对 SELinux 上下文无效，必须用restorecon或semanage
/run 是磁盘目录、没意识到它是个内存文件系统且容量极小。 
