逻辑升级才是生产环境的稳妥选择，因in-place升级易因sql_mode、字符集、系统表冲突等导致启动失败或数据损坏，而逻辑升级通过mysqldump+新实例导入可隔离语义差异、提前暴露问题。
原地升级风险高，逻辑升级才是生产环境的稳妥选择。 直接替换二进制、复用旧数据目录的 in-place 升级，看似省事，但一旦遇到字符集乱码、系统表结构冲突或 sql_mode 不兼容，轻则启动失败，重则数据目录损坏无法回退。而逻辑升级（如 mysqldump + 新实例导入）虽耗时长、需额外资源，却能彻底隔离 5.7 和 8.0 的语义差异，把问题暴露在测试阶段，而不是凌晨三点的生产库上。
为什么 in-place 升级常在启动阶段就失败
MySQL 8.0 启动时会对数据字典和系统表做强校验，很多 5.7 中“能跑”的状态，在 8.0 下直接被判定为非法：
-
NO_AUTO_CREATE_USER已从sql_mode中彻底移除，若配置文件或备份 SQL 中还保留该值，mysqld将拒绝启动，并报错：Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' - 5.7 使用
utf8mb3字符集建的表，若含四字节 emoji 或生僻汉字，在 8.0 启动时可能触发元数据校验失败（尤其当列注释含 utf8mb3 乱码时） - 5.7 的
mysql系统库中若存在自定义同名表（如columns、events），会与 8.0 新增的数据字典表冲突，导致升级中断 - 使用
MyISAM引擎的系统表（如mysql.plugin）在 8.0 中已被强制转为InnoDB，但 in-place 过程中若发现表损坏或格式异常，不会自动修复，而是报ERROR并退出
逻辑升级的关键实操步骤
核心思路是“旧库只读导出 → 新库干净导入 → 应用灰度切流”，全程不碰原生产数据目录：
- 导出时务必加
--single-transaction和--set-gtid-purged=OFF（若未启用 GTID），避免锁表或 GTID 冲突；对大库可分库导出，用mysqldump --databases db1 db2 - 导入前，在 MySQL 8.0 实例中手动执行
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';，先对齐基础模式，再导入，减少语法报错 - 导入后立即检查：运行
SELECT DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'your_db';，确认默认校对规则是否为utf8mb4_0900_ai_ci；用SHOW CREATE TABLE验证关键表的CHARACTER SET是否已自动升为utf8mb4 - 认证插件必须显式处理：8.0 默认用
caching_sha2_password，老应用连接会报Client does not support authentication protocol；建用户时要加IDENTIFIED WITH mysql_native_password，或升级客户端驱动
升级检查工具 util.checkForServerUpgrade() 怎么用才有效
这个工具不是“一键通过”就完事的，它返回的 ERROR 必须解决，WARNING 很多也得改——比如报告 “Table uses utf8mb3 charset”，光看提示没用，得定位到具体库表并执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;：
- 运行命令示例：
mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({targetVersion: '8.0.39'})"，注意targetVersion要和你实际升级目标一致 - 输出中的
ERROR类型项（如 “Found invalid default value for column”、“Foreign key constraint name exceeds 64 characters”）必须在升级前手工修复，否则 in-place 升级必然中断 - 工具不会检查应用层兼容性，比如 ORM 是否调用了已移除的
query_cache相关接口，或 SQL 中用了 8.0 新增保留字RANK作列名（需加反引号） - 检查结果里出现
NOTICE表示系统能自动处理（如自动升级mysql系统表），但你要知道它做了什么——例如它会把mysql.user表中plugin字段从mysql_native_password改为caching_sha2_password，这直接影响后续连接
真正难的不是命令怎么敲，而是哪些 WARNING 会演变成凌晨的 P1 故障。比如 GROUP BY 隐式排序在 5.7 里默认生效，到了 8.0 就没了，应用如果依赖这个行为却没写 ORDER BY，查询结果顺序一变，下游定时任务就可能误删数据——这种问题，只有在逻辑升级后的全链路回归里才能暴露出来。
