升级失败应先查日志：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也救不回来——这时候物理备份就是唯一退路。