不能直接升级主库，因5.7→8.0存在系统表、认证插件、SQL模式、JSON行为等多重不兼容，易致连接失败、查询报错、事务异常；须通过只读延迟临时从库验证，运行mysqlcheck检查兼容性，切换时调整Router权重并禁用super_read_only，同时校验字符集排序规则及监控脚本适配。
为什么不能直接升级主库？
MySQL大版本升级（比如 5.7 → 8.0）不是“改个配置重启就行”的事。mysql_upgrade 已在 8.0.16+ 被移除，系统表结构、认证插件（caching_sha2_password vs mysql_native_password）、SQL 模式默认值（如 STRICT_TRANS_TABLES）、JSON 字段行为都可能不兼容。直接升级主库，应用连不上、查询报错、事务异常都是大概率事件——业务感知强烈，根本谈不上“透明”。
临时从库必须用“只读 + 延迟”双保险
搭建临时从库不是为了备份，而是为了验证和缓冲。关键点在于：
- 从库启动时必须加
--skip-slave-start，先不拉日志，确认配置无误再启同步
- 同步开启后立即执行
STOP SLAVE SQL_THREAD，让 IO 线程继续收 binlog，SQL 线程暂停——这样能保留一段可回退的时间窗口
- 延迟设置建议至少
MASTER_DELAY = 3600（1 小时），不是为了防误操作，而是给 QA 留出完整跑一遍核心链路的时间
- 务必在从库上运行
mysqlcheck --all-databases --check-upgrade，它会真实检查表是否兼容 8.0，比看文档靠谱得多
切换前必须绕过 MySQL Router 的自动重连陷阱
很多业务用 mysql-router 或 proxySQL 做读写分离，但它们默认不会感知底层主从角色变化。常见错误现象是：切完主库，Router 还往旧主（已降为从）发写请求，报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。解决方法只有两个：
- 切换前，在 Router 配置里把旧主的权重设为
0，并 reload 配置（不是 restart）
- 切完后，立刻在新主上执行
SET PERSIST super_read_only = OFF（注意是 PERSIST，否则重启失效）
- 别依赖 DNS 切换或 VIP 漂移——MySQL 客户端缓存 DNS、连接池复用旧地址，都会导致部分请求打到下线节点
8.0 的默认字符集和排序规则会悄悄改坏数据
MySQL 5.7 默认 utf8mb4，但排序规则是 utf8mb4_general_ci；8.0 默认变成 utf8mb4_0900_ai_ci。差别看似小，实际影响极大：
- 已有索引如果建在
VARCHAR 字段上，且没显式指定 COLLATE，升级后索引可能失效（EXPLAIN 显示 Using filesort 或全表扫描）
-
GROUP BY、ORDER BY 结果顺序可能变，尤其含 emoji 或多语言混合数据时
- 最隐蔽的坑：从库升级后，即使同步正常，
SELECT ... WHERE name = '张' 可能查不到原数据——因为新排序规则对中文的比较逻辑变了
所以临时从库上必须跑一遍 SELECT * FROM information_schema.COLUMNS WHERE COLLATION_NAME LIKE 'utf8mb4%'，逐个确认关键字段的排序规则是否显式声明。
- 从库启动时必须加
--skip-slave-start，先不拉日志，确认配置无误再启同步 - 同步开启后立即执行
STOP SLAVE SQL_THREAD，让 IO 线程继续收 binlog，SQL 线程暂停——这样能保留一段可回退的时间窗口 - 延迟设置建议至少
MASTER_DELAY = 3600（1 小时），不是为了防误操作，而是给 QA 留出完整跑一遍核心链路的时间 - 务必在从库上运行
mysqlcheck --all-databases --check-upgrade，它会真实检查表是否兼容 8.0，比看文档靠谱得多
切换前必须绕过 MySQL Router 的自动重连陷阱
很多业务用 mysql-router 或 proxySQL 做读写分离，但它们默认不会感知底层主从角色变化。常见错误现象是：切完主库，Router 还往旧主（已降为从）发写请求，报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。解决方法只有两个：
- 切换前，在 Router 配置里把旧主的权重设为
0，并 reload 配置（不是 restart）
- 切完后，立刻在新主上执行
SET PERSIST super_read_only = OFF（注意是 PERSIST，否则重启失效）
- 别依赖 DNS 切换或 VIP 漂移——MySQL 客户端缓存 DNS、连接池复用旧地址，都会导致部分请求打到下线节点
8.0 的默认字符集和排序规则会悄悄改坏数据
MySQL 5.7 默认 utf8mb4，但排序规则是 utf8mb4_general_ci；8.0 默认变成 utf8mb4_0900_ai_ci。差别看似小，实际影响极大：
- 已有索引如果建在
VARCHAR 字段上，且没显式指定 COLLATE，升级后索引可能失效（EXPLAIN 显示 Using filesort 或全表扫描）
-
GROUP BY、ORDER BY 结果顺序可能变，尤其含 emoji 或多语言混合数据时
- 最隐蔽的坑：从库升级后，即使同步正常，
SELECT ... WHERE name = '张' 可能查不到原数据——因为新排序规则对中文的比较逻辑变了
所以临时从库上必须跑一遍 SELECT * FROM information_schema.COLUMNS WHERE COLLATION_NAME LIKE 'utf8mb4%'，逐个确认关键字段的排序规则是否显式声明。
0，并 reload 配置（不是 restart）SET PERSIST super_read_only = OFF（注意是 PERSIST，否则重启失效）utf8mb4，但排序规则是 utf8mb4_general_ci；8.0 默认变成 utf8mb4_0900_ai_ci。差别看似小，实际影响极大：
- 已有索引如果建在
VARCHAR字段上，且没显式指定COLLATE，升级后索引可能失效（EXPLAIN显示Using filesort或全表扫描） -
GROUP BY、ORDER BY结果顺序可能变，尤其含 emoji 或多语言混合数据时 - 最隐蔽的坑：从库升级后，即使同步正常，
SELECT ... WHERE name = '张'可能查不到原数据——因为新排序规则对中文的比较逻辑变了
SELECT * FROM information_schema.COLUMNS WHERE COLLATION_NAME LIKE 'utf8mb4%'，逐个确认关键字段的排序规则是否显式声明。
真正难的不是命令怎么敲，是哪些地方改了你根本不知道它改了。比如 information_schema.PROCESSLIST 在 8.0 里被 performance_schema.threads 替代，监控脚本里还写着旧表名，凌晨切完就丢指标。这种细节，文档不会标红，只能靠提前在临时从库里翻日志、查视图、跑压测。
