灰度切换必须显式接管路由逻辑，禁用自动读写分离框架，定义独立数据源并按开关/标识选择，通过ProxySQL规则或应用层解析Header等精准分流至灰度从库。
灰度切换必须绕开自动读写分离
应用框架自带的读写分离（比如 MyBatis 的 AbstractRoutingDataSource、ShardingSphere 的默认路由）会把读请求随机打到任意从库，甚至可能回写主库——这会让灰度流量完全不可控。你得显式接管路由逻辑，而不是依赖“它应该能识别”。
关键动作是：在应用里定义两套独立的 DataSource 实例（或连接池），一套指向旧库组，一套指向新库组；再通过开关、用户 ID 哈希、HTTP Header（如 X-Gray: true）等条件决定用哪一套。
- Java 场景下，用 Spring 的
@Qualifier注解区分两个DataSourceBean，业务方法里根据规则手动获取对应数据源 - Go 场景下，维护两个全局
*sql.DB变量，用中间件解析请求上下文后选择执行器 - 禁用所有 ORM 层的自动从库路由配置，哪怕只留一行
read_only=true都可能被误触发
SQL hint 不会被 MySQL 执行引擎识别
/*+ READ_FROM_SLAVE */ 这类注释只是给代理层（如 ProxySQL）或自研路由组件看的，MySQL 服务端压根不解析也不生效。如果你没部署 ProxySQL 或类似中间件，光加注释等于没加。
真正起作用的是：ProxySQL 的 mysql_query_rules 表中匹配 digest 或正则 match_pattern 的规则，把带特定标记的 SQL 转发到指定 hostgroup（即灰度从库组）。
- 别用
SELECT SLEEP(1)测延迟——它不走查询缓存，也不触发复制延迟检测，结果毫无参考价值 - 验证时优先选真实业务 SQL，比如商品详情页的
SELECT * FROM products WHERE id = ?，并确认其返回结果与主库一致 - ProxySQL 规则需提前加载并 reload，不能靠重启生效；上线前务必用
PROXYSQL ADMIN手动测试规则命中情况
灰度从库必须调低并行复制参数
MySQL 8.0+ 默认开启并行复制（replica_parallel_workers > 0），但并行线程间可能存在事务依赖顺序错乱，导致灰度环境看到“未来数据”或“跳变状态”，干扰验证结论。
正确做法是：为灰度专用从库单独设置 replica_parallel_workers = 0（或设为 1），强制串行回放 binlog。这不是性能妥协，而是为了确保灰度看到的数据变更顺序与主库严格一致。
- 不要碰
max_replication_delay或replica_checkpoint_group——这些参数对单条 SQL 延迟无效，反而容易引发复制中断 - 灰度从库的
server_id必须唯一，且不能与其它从库重复，否则 binlog event 可能被跳过 - 每台灰度从库应独立监控
Seconds_Behind_Master和Replica_SQL_Running_State，延迟突增要立刻告警
哪些查询绝对不能进灰度从库
不是所有读请求都适合灰度。以下三类 SQL 必须拦截，直接打主库：
- 事务内后续读（
BEGIN; INSERT ...; SELECT ...;）——强一致性要求，从库延迟会导致幻读 - 写后立即读（如注册成功后马上查用户信息）——即使延迟 100ms，也大概率读不到刚写的记录
- 报表类聚合查询（
GROUP BY + SUM()）——若依赖隐式排序（MySQL 5.7 默认行为），而目标库无此特性，结果会错乱
真正适合灰度的是「可容忍秒级延迟」的只读场景：后台定时任务拉取统计快照、商品类目缓存刷新、非实时搜索建议等。判断依据不是 SQL 类型，而是业务语义是否允许延迟。
最容易被忽略的是：灰度开关本身不能只靠配置中心下发一次就完事。它必须支持运行时热更新，并在每次数据库操作前重新评估——因为一个请求生命周期内，用户身份或上下文可能动态变化。
