灰度方案必须从双写阶段开始设计，而非切库时才启动；需同步解决write-through路由、binlog增量同步兜底及shadow read校验，其中shadow read用于比对新旧库只读结果一致性，缺之则无法发现隐式数据污染。
灰度方案必须从双写阶段开始设计
升级不是切库那一刻才开始的，而是从双写启动时就决定了灰度成败。你不能先完成全量迁移再考虑灰度——那样等于把数据一致性、路由策略、监控告警全堆到上线前一刻，风险爆炸式上升。
双写阶段要同时解决三件事：write-through 路由逻辑、binlog 增量同步兜底、以及 shadow read 校验开关。其中 shadow read 是最容易被跳过的环节：它指在双写期间，对新库发起只读查询但不返回给用户，仅用于比对结果一致性。没这层校验，你根本不知道 GROUP BY 行为变更或隐式类型转换是否已悄悄污染了新库数据。
- 双写必须覆盖所有写入路径，包括定时任务、后台 Job、管理后台直连 SQL
- 避免用应用层双写（如 Spring @Transactional 多数据源），优先走中间件层（如 ShardingSphere、MyCat）或 DB Proxy 层控制
- 双写开启后立即启用
pt-table-checksum或自研指纹比对，而不是等迁移结束才校验
灰度流量路由不能只靠用户 ID 或 IP
TB 级数据库通常对应复杂业务模型，单一维度路由会快速暴露倾斜和边界问题。比如按 user_id % 100 切 1% 流量，看似均匀，但若某几个 user_id 关联了千万级订单记录，实际压到新库的 I/O 和锁竞争可能远超预期。
真实可行的路由策略是组合标签：业务线 + 数据热度 + 操作类型。例如只对「订单中心」中「创建订单」且「用户近 7 日活跃度 < 3」的请求放行到新库。这类规则必须可动态加载，不能硬编码进应用。
- 路由决策点应前置到网关或 API 层，避免每个服务都重复实现逻辑
- 必须支持运行时关闭灰度开关，且关闭后旧库写入不受影响（即双写不停）
- 禁止使用 MySQL 自增主键、时间戳等易受时钟漂移影响的字段做路由依据
新库稳定性验证不能只看 QPS 和 P99
TB 级场景下，慢查询可能藏在冷数据扫描、大事务回滚、或者统计信息未更新的索引失效里。只盯 QPS 和 P99 会漏掉关键问题。8.4 的 innodb_stats_persistent 默认开启，但如果你从 5.7 升上来，旧表的统计信息可能长期未刷新，导致优化器选错执行计划。
必须在灰度期间跑三类专项验证：
- 随机抽样 50 个高频 SQL，在新库上执行
EXPLAIN FORMAT=TREE，比对与旧库的执行计划差异 - 对每个分库分表的物理文件做
inodes和fragmentation检查，TB 级容易出现页分裂堆积 - 模拟一次主库 crash 后的
crash recovery时间，8.4 的 redo log 写入策略变化会影响恢复耗时
回滚能力必须在灰度期就实测过
很多团队把回滚当成“理论上可行”的预案，直到真要切回去才发现：双写期间产生的新库 binlog 没法直接反向应用，mysqldump 导出 TB 级数据要 8 小时以上，而旧库的 relay log 已被 purge。真正的回滚不是“切回旧连接”，而是“让业务无感地继续用旧库，且不丢任何双写期间的数据”。
这就要求你在灰度启动前，就部署好双向同步通道，并定期用 mysqlbinlog --base64-output=DECODE-ROWS -v 抽样解析新库 binlog，确认其 DML 可被旧库兼容解析（注意 8.4 的 binlog_row_image 默认值已变）。
- 回滚触发条件不能只依赖人工判断，需接入核心指标：新库
Threads_running > 200持续 5 分钟、或Innodb_row_lock_waits突增 300% - 回滚脚本必须包含自动清理新库残留临时表、重置 GTID set、关闭双写开关三步原子操作
- 哪怕只灰度 0.1% 流量，也必须完整走一遍回滚演练，否则上线当天就是灾难
