影子库升级必须用目标版本初始化实例并严格对齐配置：先用新版本执行mysqld --initialize-insecure创建干净数据目录，再导入数据；同步时避免mysqldump，改用mysqlpump/mydumper并手动处理存储过程与角色权限；需重点验证8.0权限模型、SQL模式及utf8mb4字符集兼容性。
影子库必须和生产库同版本启动
跨版本升级时，直接拿新版本 MySQL 启动旧数据目录，极大概率报错 Table 'mysql.user' doesn't exist 或卡在 mysqld --initialize-insecure 阶段——因为新版本的系统表结构、初始化逻辑、甚至 datadir 目录权限校验都变了。影子库不是“跑个新 bin 就行”，它得先用目标版本完整初始化一套干净实例，再导入数据。
- 正确做法：用待升级的目标 MySQL 版本（如 8.0.33）执行
mysqld --initialize-insecure --datadir=/path/to/shadow_datadir - 之后启动该实例：
mysqld --defaults-file=/path/to/shadow.cnf，确保配置中basedir和datadir指向新版本路径和新数据目录 - 切勿复用老版本的
ibdata1或mysql/子目录，否则启动失败或元数据损坏
数据同步不能只靠 mysqldump
mysqldump 默认导出的是兼容性优先的 SQL，会丢掉 8.0+ 的关键特性：比如 mysql.user 表里的 authentication_policy 字段、角色权限继承链、JSON 列的 CHECK 约束、隐藏索引状态。这些在影子库里一执行就报错或静默失效。
- 用
mysqldump --no-tablespaces --skip-triggers --set-gtid-purged=OFF --databases db1 db2导出结构 + 数据（跳过存储引擎特定元数据） - 触发器、存储过程、函数必须单独用
SHOW CREATE PROCEDURE提取，手动检查语法兼容性（比如 5.7 的DEFINER在 8.0 中可能被拒绝） - 大表建议改用
mysqlpump（MySQL 5.7.8+）或mydumper，它们支持并行、更准的字符集处理和 GTID 元信息保留
灰度验证要覆盖权限模型变更点
MySQL 8.0 的权限体系重构是最大雷区：mysql.user 表字段大幅调整，密码策略默认启用，root@localhost 不再自动拥有所有权限，且 CREATE USER 语句行为变化。影子库里跑通 DML 不代表权限就对了。
- 重点验证：应用连接用的账号是否能在影子库执行
SELECT * FROM performance_schema.events_statements_summary_by_digest（需要SYSTEM_VARIABLES_ADMIN权限） - 检查
SELECT CURRENT_USER(), USER()返回值差异，确认 definer 和实际登录用户权限边界 - 用
SELECT * FROM mysql.role_edges和mysql.default_roles核对角色继承是否生效（5.7 没这俩表） - 测试
SET PERSIST max_connections = 1000是否成功——8.0 动态变量持久化依赖PERSIST_ROLES权限，老账号很可能没这个
SQL 模式与字符集必须显式对齐
MySQL 5.7 默认 sql_mode 是空的，8.0 开箱即用 STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION；5.7 默认 character_set_server=utf8，8.0 改成 utf8mb4。影子库若沿用老配置，看似能跑，但上线后 INSERT 超长 emoji 就截断，或者 NULL 值插入非空字段不报错反而静默转成默认值。
- 影子库配置文件中必须显式写死：
sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO -
character_set_server = utf8mb4和collation_server = utf8mb4_0900_ai_ci（注意：8.0.31+ 默认 collation 已变，别抄老配置里的utf8mb4_unicode_ci） - 建表语句里别省略
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci，尤其涉及分区表或 JSON 列时，隐式继承容易出错
真正难的不是把数据倒进去，而是确认那几条“从来不出问题”的权限语句、那几个“只是读一下”的 performance_schema 查询、还有应用连上来那一刻的字符集协商细节——这些地方没日志、不报错、但结果不对。影子库跑一天 SELECT 没事，不代表凌晨三点那个定时任务里的 REPLACE INTO 就不会因 strict mode 失败。
