必须先运行util.checkforserverupgrade()，它是oracle官方唯一推荐的跨大版本兼容性检查入口，可识别utf8mb3字符集、rank等保留字冲突、caching_sha2_password认证插件不兼容等语义级问题；而mysqlcheck --check-upgrade仅校验表结构损坏，对上述问题完全无感。
必须先跑 util.checkForServerUpgrade()，其他检查都是补漏——它能发现 utf8mb3 字符集、rank 这类保留字冲突、认证插件不兼容等语义级问题，而 mysqlcheck --check-upgrade 只管表结构，对这些完全无感。
怎么用 mysqlsh 做真实有效的升级前扫描
不是装个 mysql-shell 就能跑，必须用目标版本（比如升到 8.0.42）的二进制连接，否则检查结果不可信：
- 优先走 socket 连接：
./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({'configPath': '/etc/my.cnf'})" - 输出重定向后，只盯
ERROR级条目：比如Usage of utf8mb3 charset、Column name 'rank' is a reserved keyword，这些不改完就不能继续 - 报告里出现
caching_sha2_password plugin not supported by client？说明你的应用驱动太老，得确认mysql-connector-java ≥ 8.0.13或PyMySQL ≥ 0.10.0
哪些表和字段名会直接导致启动失败或查询报错
8.0 新增了至少 12 个保留关键字，rank、json、group、row_number 最常踩坑。不是“运行时可能出错”，而是建表或查询时立刻报 ERROR 1064 (42000)：
- 查现有表结构：
SHOW CREATE TABLE your_table，所有疑似关键字的列名、别名、表名，一律用反引号包住，比如SELECT @r:=@r+1 AS `rank` - 查系统库冲突：
SELECT table_name FROM information_schema.tables WHERE table_schema='mysql' AND table_name IN ('roles','role_edges','components')，这些是 8.0 新增系统表，同名自定义表必须重命名或删掉 - 查 MyISAM 表：
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM'，结果非空就得先ALTER TABLE ENGINE=InnoDB
my.cnf 里哪些配置项不删就卡在 “Starting MySQL”
8.0 启动时遇到 unknown variable 错误，90% 是因为配置文件里还留着 5.7 的过期参数，日志不会告诉你具体哪一行，只会卡住：
- 必须删掉：
query_cache_type、expire_logs_days（已由binlog_expire_logs_seconds替代）、innodb_file_format、max_connect_errors - 注意
slave_skip_errors部分值已失效，explicit_defaults_for_timestamp在 8.0 中行为反转，留着反而引发时间字段默认值异常 - 确认
default_authentication_plugin显式设为mysql_native_password（过渡期），否则老客户端连不上，错误日志只显示Access denied for user
真正危险的是那些不报错但悄悄改行为的地方：比如 GROUP BY 不再隐式排序、STRICT_TRANS_TABLES 默认启用、ONLY_FULL_GROUP_BY 开启后会让“select 列不在 group by 中”的语句直接失败——这些不会让你启动不了，但会让业务逻辑在上线后几天才陆续崩掉。
