mysql 8.0 启动失败应先检查 error.log 中的 aborting 或 binlog 相关错误；若出现 binlog 文件损坏或索引错乱，需停服务后备份并清理 mysql-bin.* 文件及 mysql-bin.index，同时删除 my.cnf 中 mysql 8.0 已废弃的 query_cache_size 等参数，并执行 systemctl daemon-reload 后重启。
MySQL 8.0 启动失败先看 error.log 里有没有 Aborting 或 binlog 相关报错
宝塔里点「数据库」→「错误日志」打不开？直接 SSH 查：/www/server/data/*.err，优先找最新修改时间的那个。如果日志里反复出现 Could not open log file、Failed to open log file 或 binlog index entry not found，基本就是 binlog 文件损坏或索引错乱。MySQL 8.0 对 binlog 一致性更敏感，旧版残留的 mysql-bin.0000xx 文件或损坏的 mysql-bin.index 会导致启动卡在初始化阶段，连错误都来不及写全。
删 mysql-bin.* 前必须先停服务并备份 mysql-bin.index
别直接 rm /www/server/data/mysql-bin.* —— 这会丢掉当前未刷盘的事务，还可能让 mysql-bin.index 指向已删除文件，下次启动照样失败。正确顺序是：
- 在宝塔面板点「停止」MySQL，或执行
systemctl stop mysqld - 进
/www/server/data/目录，用cp mysql-bin.index mysql-bin.index.bak备份索引文件 - 只删
mysql-bin.0000*文件（不删mysql-bin.index） - 再删一次
mysql-bin.index，让 MySQL 启动时自动重建它
注意：如果 mysql-bin.index 本身内容为空或只有半行，说明已损坏，删掉后 MySQL 8.0 会从头生成干净索引；但若里面还有合法条目，建议先人工清理无效路径再保存，避免启动时反复报 File not found。
my.cnf 里这些配置项在 MySQL 8.0 下容易冲突
升级到 8.0 后，宝塔有时没自动清理过时参数，导致启动直接退出。重点检查 /www/server/mysql/etc/my.cnf 的 [mysqld] 段：
-
query_cache_size和query_cache_type必须删掉 —— MySQL 8.0 已彻底移除查询缓存，留着就报unknown system variable -
innodb_file_format和innodb_file_per_table不用设，默认已启用；设了反而可能触发兼容性警告 -
default-storage-engine如果还是MyISAM，建议改成InnoDB，否则系统表初始化失败 - 确认没有
skip-grant-tables残留 —— 它会让权限系统失效，MySQL 8.0 启动时校验失败直接中止
改完配置务必执行 systemctl daemon-reload，再试启动。别跳过这步，宝塔有时不会自动重载 systemd 单元。
启动后立刻检查 SHOW BINARY LOGS 是否正常输出
MySQL 8.0 启动成功不等于 binlog 真恢复了。进命令行执行：mysql -uroot -p -e "SHOW BINARY LOGS;"。如果报 ERROR 1381 (HY000): You are not using binary logging，说明 log-bin 没生效，回去检查 my.cnf 是否漏写了 log-bin = mysql-bin，或路径权限不对（/www/server/data 目录需属主 mysql:mysql）。如果能列出日志文件但第一个序号不是 000001，属于正常 —— MySQL 会按现有最大序号续编，不影响使用。
真正容易被忽略的是：MySQL 8.0 默认开启 binlog_expire_logs_seconds（而非旧版的 expire_logs_days），如果值设得太小（比如 3600 秒），刚启动几分钟就自动 purge，后续查问题时发现日志“莫名其妙没了”。需要长期保留可显式设大些，例如 binlog_expire_logs_seconds = 2592000（30天）。
