MySQL启动失败主因是/www/server/data目录权限错误（需chown -R mysql:mysql）或/etc/my.cnf含MySQL 8.x废弃参数（如query_cache_size），须删除并重载配置。
MySQL 启动失败，八成是 /www/server/data 目录权限不对，或 /etc/my.cnf 里写了 MySQL 8.x 不认的参数（比如 query_cache_size）。
检查 /www/server/data 所有者是否为 mysql
MySQL 进程默认以 mysql 用户身份运行，如果数据目录归 root 或其他用户所有，它连文件都打不开，直接退出，日志里往往只留一句 “The server quit without updating PID file”。
- 执行
ls -ld /www/server/data，确认输出中 owner 和 group 都是mysql - 如果不是，立刻修复：
chown -R mysql:mysql /www/server/data - 顺手检查下父目录
/www/server权限，不能是700或完全禁止组/其他读取，否则mysql用户可能进不去 - 特别注意：宝塔重装或迁移后，
data目录常被保留但权限没同步，这是高频踩坑点
验证 /etc/my.cnf 是否含 MySQL 8.x 已废弃参数
宝塔的“性能调整”功能会往配置里硬塞 query_cache_type 和 query_cache_size，这两个在 MySQL 8.0.3+ 完全移除，只要出现就启动失败，且错误日志里不报具体哪行错，只显示 “Aborting”。
- 打开配置：
cat /etc/my.cnf | grep -i "query_cache" - 如果输出非空，直接删掉整行（包括
query_cache_type和query_cache_size） - 顺便检查是否有
innodb_log_file_size被手动改得过大（比如 >1G），这在小内存机器上也会导致初始化失败 - 改完必须执行
bt 16（重载 MySQL 配置）或systemctl restart mysqld，别只改不重启
用官方脚本快速定位真实错误
别靠猜，宝塔自带的 sql-repair.sh 能绕过面板封装，直接调用 MySQL 二进制启动并输出原始错误，比看面板日志准得多。
- 下载并运行：
wget -O sql-repair.sh http://download.bt.cn/install/sql-repair.sh && sh sql-repair.sh - 重点盯住最后几行：出现
Can't init tc log或File './mysql-bin.xxxxx' not found，说明 binlog 索引和实际文件不一致，要进/www/server/data手动核对mysql-bin.index和文件列表 - 如果报
errno: 13（Permission denied），不是权限问题就是 SELinux 没关；执行getenforce，返回Enforcing就临时关掉：setenforce 0
真正卡住的地方往往不在日志明面上——比如 mysql-bin.index 多写了一行已删除的 binlog，或者 ibdata1 文件损坏但没报 I/O 错误。动手前先做快照，修配置、改权限、删索引，每步都要验证是否生效，而不是一口气全干完再试。
