必须经 mysql 5.7 中转升级：官方仅支持 5.6→5.7→8.0→8.4 线性路径，跳过 5.7 会导致 mysql_upgrade 失效、系统表损坏、gtid 复制中断及启动失败。
不能直接从 MySQL 5.6 升级到 8.4，官方明确不支持——你必须用 5.7 做中间跳板，否则 mysqld 启动失败、系统表损坏、用户认证全挂，不是报错就是丢权限。
为什么必须走 5.7 这一跳
MySQL 官方升级路径是线性的：5.6 → 5.7 → 8.0 → 8.4。跳过 5.7 会触发两层硬性阻断：
-
mysql_upgrade工具在 5.6 → 8.4 场景下完全不可用：它只支持相邻主版本间修复系统表结构，而 5.6 的mysql.user表字段（如password）、索引定义、插件注册方式与 8.4 的authentication_string+caching_sha2_password根本不兼容 - GTID 和复制协议在 5.6 与 8.4 之间存在语义断裂：例如 5.6 的
log_slave_updates=OFF默认行为在 8.4 下被强制校验，主从初始化直接中断
实测中，跳过 5.7 直接替换二进制文件后，mysqld --initialize 会静默失败，错误日志只显示 InnoDB: Assertion failure，无具体定位线索。
5.6 → 5.7 迁移时必须处理的三个雷区
这一步看似过渡，但埋着最隐蔽的坑——很多团队在这卡住数天，最后发现是字符集或 SQL 模式没对齐。
- 导出前必须显式加
--default-character-set=utf8mb4：5.6 默认character_set_server=utf8（即 utf8mb3），而 5.7 开始拒绝创建 utf8mb3 字符集的表；不加参数会导致导入时ERROR 1071 (42000): Specified key was too long - 禁用
NO_AUTO_CREATE_USER：5.6 的GRANT语句隐式建用户，5.7 默认关闭该行为，导入含GRANT ... IDENTIFIED BY的 dump 会报ERROR 1133 (HY000)；解决方法是在 5.7 配置里临时加sql_mode=NO_AUTO_CREATE_USER,STRICT_TRANS_TABLES - 跳过
mysql系统库导出：5.6 的mysql.plugin表在 5.7 中已删除，强行导入会导致Table 'mysql.plugin' doesn't exist并中断整个恢复流程；用--ignore-table=mysql.plugin屏蔽
5.7 → 8.4 迁移的关键动作清单
这步重点不是“能不能导”，而是“导完能不能用”——8.4 对语法和权限更苛刻，旧数据容易在运行时暴露问题。
- 导入前在 8.4 实例执行
SET GLOBAL sql_mode = ''：绕过严格模式对空值、零日期、分组字段的校验，避免ERROR 1364或ERROR 1055；上线后再按业务需要逐步收紧 - 用户认证必须重置：5.7 导出的用户仍用
mysql_native_password，而 8.4 默认禁用该插件；导入后立刻批量执行ALTER USER 'u'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd' - 检查并重建所有
FULLTEXT索引：5.7 的全文索引结构在 8.4 中不兼容，查询会返回空结果但不报错；用SHOW CREATE TABLE t检查，发现FULLTEXT KEY就需ALTER TABLE t DROP INDEX ft_idx, ADD FULLTEXT(ft_col)
迁移后最容易被忽略的验证点
很多人跑完 mysql 就以为结束了，但以下三项不手动验证，上线后必出故障：
-
SELECT COUNT(*) FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%DEFINER=%'：确认所有视图的DEFINER用户在 8.4 中真实存在，否则查询视图时报ERROR 1449 -
SELECT * FROM mysql.user WHERE plugin = 'mysql_native_password'：只要还有结果，说明有用户没切到caching_sha2_password，客户端连接会静默失败 - 用实际业务 SQL 跑一遍
EXPLAIN FORMAT=TREE：8.4 的优化器对 CTE、窗口函数重写了执行计划，某些在 5.6/5.7 下走索引的语句，在 8.4 可能变成全表扫描，且不报错
