不能直接原位升级，MySQL官方明确不支持5.7→8.0跨大版本in-place升级；必须采用逻辑导出（mysqldump）+干净安装路径，否则易致元数据损坏、系统表崩溃或权限失效。
不能直接原位升级。MySQL 官方明确不支持跨大版本的 in-place upgrade（比如 5.7 → 8.0），强行执行 mysqld --upgrade 或替换二进制文件极大概率导致元数据损坏、系统表崩溃或无法启动。
为什么 MySQL 5.7 到 8.0 不允许原位升级
8.0 彻底重构了数据字典（从 MyISAM 表转为 InnoDB 系统表），重写了 mysql 库结构，user 表字段大幅变更（如 plugin、account_locked），且默认字符集/排序规则、密码认证插件（caching_sha2_password）、SQL 模式都发生不兼容变更。5.7 的 mysql 表结构无法被 8.0 的 server 正确识别和加载。
常见错误现象包括：
- 启动时卡在
Starting MySQL... [FAILED]，日志反复报Table 'mysql.user' doesn't exist或Unknown table engine 'InnoDB' -
mysql_upgrade报错Failed to open mysql.db或直接 segfault - 即使启动成功，
SELECT USER();返回空，所有权限失效
安全升级的唯一推荐路径：逻辑导出 + 干净安装
必须走 mysqldump（或 mydumper）全量逻辑导出 → 停旧实例 → 安装 MySQL 8.0 → 初始化空实例 → 导入 → 校验 → 切流。这是生产环境唯一可控、可回滚的方式。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
实操关键点：
- 导出前务必执行
SET GLOBAL innodb_fast_shutdown = 0;，确保脏页刷盘，避免 5.7 shutdown 不干净导致 8.0 启动时 redo 解析失败 - 使用
mysqldump --all-databases --routines --events --triggers --single-transaction --set-gtid-purged=OFF；若用 GTID，需先RESET MASTER并确认无复制依赖再导出 - 8.0 安装后首次启动前，必须删除
datadir下所有残留文件（尤其ib_logfile*、ibdata1），否则会复用 5.7 的旧系统表空间，引发 crash - 导入后立即运行
mysql_upgrade（8.0.16+ 已弃用，但 8.0.0–8.0.15 仍需）；8.0.16+ 改为自动升级，但需确认mysql.schema表存在且非空
升级后必须验证的三项硬指标
不能只看 SELECT VERSION(); 返回 8.0.x 就认为成功。以下三处任一失败即说明升级未真正就绪：
-
SELECT COUNT(*) FROM mysql.user;结果必须 > 0（5.7 的 user 表字段已被 8.0 自动映射，但若导入时跳过mysql库或权限表损坏，此处为 0） -
SHOW VARIABLES LIKE 'default_authentication_plugin';应返回caching_sha2_password；若仍是mysql_native_password，说明配置未生效或用户未重置密码 - 连接测试必须用新协议：
mysql -u root -p --default-auth=caching_sha2_password；旧客户端（如 MySQL 5.7 mysql 命令行）默认不支持该插件，会报Authentication plugin 'caching_sha2_password' cannot be loaded
最易被忽略的是字符集迁移细节：5.7 默认 utf8mb4 但排序规则是 utf8mb4_general_ci，而 8.0 默认改为 utf8mb4_0900_as_cs。应用若未显式指定 COLLATE，建表语句可能隐式创建新排序规则，导致 ORDER BY / GROUP BY 行为变化——这不会报错，但业务查询结果可能悄然偏移。
