升级失败应先查日志：mysql 错误日志中的 error 或 my- 开头提示（如 my-010020、unknown variable）直指原因，linux 用 sudo tail -n 50 /var/log/mysqld.log，windows 查 data 主机名。err。
看日志，别猜原因
升级失败后第一件事不是重试或删配置，是立刻查错误日志。MySQL 不会告诉你“我哪里不高兴”，但日志里每行 ERROR 或MY-开头的提示都是明确线索：MY-010020 Data Dictionary initialization failed说明数据字典升级卡住了，Unknown variable 'query_cache_type'代表配置里写了 8.0 已移除的参数，InnoDB: The system tablespace must be writable则直指权限或磁盘问题。
Linux 下快速定位：sudo tail -n 50 /var/log/mysqld.log；不确定路径就跑 mysqld --help --verbose 2>/dev/null | grep "log-error"。Windows 用户去data 你的主机名。err 里翻——跳过这步，等于蒙眼拧螺丝。
配置文件不兼容是最常见硬伤
MySQL 5.7→8.0 不是“换二进制就行”，很多 my.cnf 里的老参数会让新版本直接拒启。比如 query_cache_type、explicit_defaults_for_timestamp=OFF、sql-mode="NO_AUTO_CREATE_USER" 全在 8.0 废弃名单上。
- 先用
mysqld --defaults-file=/etc/my.cnf --validate-config验证语法（5.7.16+ 支持） - 再对照官方文档“Removed Options and Variables”章节逐条清理
- 临时救急：把
[mysqld]段全注释掉，用最小配置启动，确认能跑后再加回关键项
系统表没升级 = 登录都报错
升级后连 mysql -u root -p 都失败，或者一执行 ALTER USER 就报 system tables don't support MyISAM，基本是系统表结构没跟上。8.0 已将mysql.user 等表从 MyISAM 强制转为 InnoDB，旧数据目录必须完成结构迁移。
注意：mysql_upgrade在 8.0.16+ 已弃用，服务器会自动触发升级，但可能卡住或跳过。这时得手动干预：
- 停掉 MySQL 服务
- 用新版本
mysqld启动并强制升级：mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE - 观察日志是否出现
Upgrading system tables和成功标记，再正常启服务
权限、SELinux、tmpdir 这些细节最容易漏
看着日志没报错，但服务就是起不来？往往是系统层拦住了。常见三类隐形障碍：
-
chown -R mysql:mysql /var/lib/mysql——升级常改错归属，尤其从 root 手动解压安装包后 -
restorecon -R /var/lib/mysql——CentOS/RHEL 启用 SELinux 时，上下文丢失会导致“Permission denied”却无明确报错 -
mysql_upgrade -u root -p --tmpdir=/var/tmp/——默认用/tmp，而某些环境/tmp挂载了noexec或nosuid，导致临时文件创建失败
跨大版本（如 5.6→8.0）千万别跳 5.7 中转，否则 InnoDB 数据字典格式不匹配，--upgrade=FORCE也救不回来——这时候物理备份就是唯一退路。
