大概率是权限问题，因mysqld未启动就退出，需检查/www/server/data归属、父目录权限、selinux及pid-file路径是否匹配且可写。
MySQL 启动卡在 “PID file could not be found” 是权限问题吗？
大概率是。这不是 MySQL 崩溃了，而是 mysqld 进程压根没跑起来——它连写 PID 文件这一步都失败了，就直接退出。你看到的错误只是表象，真实原因藏在启动瞬间的输出里。别信面板状态，也别急着删 mysql.pid，先看它到底被哪只手拦住了。
为什么 chown -R mysql:mysql /www/server/data 还是不生效？
常见有三个漏点：
• /www/server/data 父目录（比如 /www/server）权限太严，导致 mysql 用户无法进入子目录
• SELinux 或 AppArmor 在后台拦截（宝塔默认关，但某些定制系统会开）
• 用 sudo chown 改了属主，但忘了改组，而 MySQL 实际以 mysql:mysql 身份运行，组权限缺失也会拒绝写入
验证最简单：用 MySQL 真实身份试写：sudo -u mysql touch /www/server/data/test.pid && rm /www/server/data/test.pid。失败就说明权限链断在哪一环。
my.cnf 里 pid-file 路径设对了，为啥还是报错？
pid-file 的父目录必须存在、可写、且属主匹配。宝塔默认 datadir = /www/server/data，但很多人没改 pid-file，让它指向 /var/run/mysqld/mysqld.pid ——这个路径在宝塔环境通常根本不存在，更别说可写。必须显式改成同级路径：
• 编辑 /www/server/mysql/my.cnf
• 在 [mysqld] 段下加一行：pid-file = /www/server/data/mysql.pid
• 确保 /www/server/data/ 下没有残留的 mysql.pid（rm -f /www/server/data/mysql.pid）
• 修改后不要点面板“重启”，先跑命令：/etc/init.d/mysqld start，再立刻检查：ps aux | grep mysqld 和 ls -l /www/server/data/mysql.pid
磁盘满和权限问题怎么快速区分？
看 mysqld 启动时的原始报错：
• 出现 Operating system error number 13 → 权限问题（Permission denied）
• 出现 Operating system error number 28 → 磁盘满（No space left on device）
• 出现 No such file or directory → pid-file 路径的父目录不存在（比如写了 /var/run/mysqld/ 但该目录根本没创建）
执行 df -h /www 是必须动作，但 ≥95% 使用率才真正危险；清理优先清 /www/wwwlogs/，别碰 /www/server/data/ib_logfile*，那俩文件删了可能让 InnoDB 拒绝启动。
真正容易被忽略的是：权限修复后，残留的 mysql.pid 文件如果还躺在那儿，mysqld_safe 会误判进程还在运行，直接跳过启动流程——它根本不会尝试写新 PID，也就不会报任何错误，只会静默失败。
