90%是因pid-file父目录不存在或mysql用户无写权限，需查真实路径、创建并授权父目录（如/var/run/mysqld）、检查/run分区空间与inodes是否耗尽，并排查残留进程及错误日志。
MySQL 启动报 “The server quit without updating PID file” 或 “Can't create/write to file … pid-file” 时，90% 不是配置写错了，而是 mysqld 进程根本没跑起来——它连写 mysql.pid 这一步就被系统拦下了。必须从权限、路径、磁盘三方面同步验证，缺一不可。
确认 pid-file 配置路径是否真实存在且父目录可写
MySQL 不会自动创建 pid-file 的上级目录，比如配置了 pid-file = /var/run/mysqld/mysqld.pid，但 /var/run/mysqld/ 根本不存在，就会直接报 Errcode: 2 (No such file or directory)。
- 先查实际生效的路径：
mysqld --print-defaults | grep pid-file，或打开/etc/my.cnf（或/www/server/mysql/my.cnf）看[mysqld]段下的pid-file值 - 检查父目录是否存在：
ls -ld $(dirname /var/run/mysqld/mysqld.pid)；若提示No such file or directory，说明目录缺失 - 手动创建并授权：
sudo mkdir -p /var/run/mysqld，然后sudo chown mysql:mysql /var/run/mysqld，再sudo chmod 755 /var/run/mysqld - 宝塔等环境常见陷阱：
datadir = /www/server/data，但pid-file还留着默认值/var/run/mysqld/mysqld.pid——这个路径在宝塔里通常根本不存在，应显式改为pid-file = /www/server/data/mysql.pid
用 mysql 用户身份实测能否写入目标路径
改完属主和权限不等于就通了。MySQL 实际以 mysql:mysql 身份运行，必须确保该用户能真正进入目录、创建文件。盲目 chmod 777 反而会让 MySQL 8.0+ 拒绝启动。
- 执行：
sudo -u mysql touch /var/run/mysqld/test.pid && rm /var/run/mysqld/test.pid；失败则说明权限链断了 - 常见断点：
/var/run父目录权限太严（如/var是root:root 755，但mysql用户无x权限就进不去子目录） - SELinux 或 AppArmor 启用时也会静默拦截，临时验证可运行：
sudo setenforce 0（仅测试用） - 某些 WSL 或 phpEnv 环境下，
mysql用户其实是当前登录用户别名，需用chown -R $USER:$USER /path/to/data并改pid-file到/tmp/mysqld.pid等明确可写位置
检查 /run 或 datadir 所在挂载点的空间与 inode 是否耗尽
即使目录存在、权限正确，mysqld 仍可能静默退出——错误日志里只显示模糊 I/O 失败，根本不提磁盘。尤其 /run 是 tmpfs，默认仅几十 MB，满后报 No space left on device，但 df -h / 看不出问题。
- 必须同时运行：
df -h /run和df -i /run；/run、/var/run、/www、/var/lib/mysql所在挂载点都要查 - 清理重点：
/www/wwwlogs/（宝塔）、/run/mysqld/下残留的.pid和.sock文件、旧.err日志 - 临时扩容 tmpfs（仅调试）：
sudo mount -o remount,size=256M /run；要持久化，得加RuntimeDirectory=mysqld到 systemd service 文件中 - 别删
ib_logfile*：它们损坏会导致 InnoDB 初始化失败，连pid-file都来不及碰
绕过面板，用命令行直启看原始报错
宝塔、phpEnv 等面板封装了太多逻辑，会掩盖关键线索。直接调用 mysqld 启动，终端立刻输出真实原因。
- 停掉所有残留进程：
ps aux | grep mysqld，kill -9掉所有疑似进程；再lsof -i :3306确认端口空闲 - 删干净残留：
rm -f /var/run/mysqld/*.pid /www/server/data/*.pid - 直启验证：
/usr/bin/mysqld --defaults-file=/etc/my.cnf --user=mysql --console（Linux）或./mysqld --defaults-file=../my.ini --console（phpEnv） - 关键判断依据：
– 卡住不动 → 路径不可写
– 报Operating system error number 13→ 权限问题（EACCES）
– 报error number 28→ 磁盘或 inode 满
– 报Can't find file: './mysql/'→datadir下缺失系统表，不是 PID 问题
真正容易被忽略的是：权限修复后，残留的 mysql.pid 文件如果还躺在那儿，mysqld_safe 会误判为已有进程在运行，直接拒绝启动——它甚至不会尝试写新文件，也不会报错。
