灰度发布需在中间层或应用层显式路由读请求至指定从库，禁用自动读写分离，配置独立连接池与复制参数，并通过SQL hint、Header等标识流量，结合ProxySQL规则精准分流。
怎么让新版本只跑在部分从库上
灰度发布本质是分流，MySQL 本身不提供「按权重分发查询」的能力，得靠中间层或应用层控制。核心思路是：把读请求显式路由到指定从库，而不是依赖 read_only=ON 自动选主/从。
常见做法是在应用配置里区分「灰度从库连接池」和「默认从库连接池」，用开关或用户标识决定走哪一组。比如 Java 应用里用 DataSource 切换，Go 里用不同 sql.DB 实例。
- 必须关闭应用框架的自动读写分离（如 MyBatis 的
AbstractRoutingDataSource默认策略），否则它可能把灰度流量又打回主库或随机从库 - 灰度从库要单独配置
replica_parallel_workers=0（MySQL 8.0+）或调低slave_parallel_workers，避免因并行复制延迟导致数据不一致，影响灰度验证 - 别直接改
max_replication_delay或replica_checkpoint_group来“加速同步”——这些参数对单条 SQL 延迟没作用，反而容易引发复制中断
如何识别并隔离灰度流量的 SQL
不是所有读都能灰度。带事务、写后立即读、依赖强一致性结果的查询，绝不能发到从库——更别说灰度从库。真正适合灰度的是那些「可容忍秒级延迟」的只读场景，比如商品详情页的类目缓存刷新、后台报表预加载。
关键判断依据是 SQL 是否被标记为 /*+ READ_FROM_SLAVE */ 这类 hint，或者是否命中应用层定义的灰度规则（如 URL 含 v=beta、Header 带 X-Gray: true）。
- MySQL 本身不解析注释 hint，所以
/*+ READ_FROM_SLAVE */必须由代理（如ProxySQL）或 ORM 解析后路由，不能指望 MySQL 执行时自动识别 - 如果用
ProxySQL，需在mysql_query_rules表里加规则匹配digest或match_pattern，把特定 SQL 指向hostgroup对应的灰度从库组 - 避免用
SELECT SLEEP(1)类测试 SQL 测延迟——它不走查询缓存、不触发复制延迟检测，结果毫无参考价值
为什么不能靠 change master to ... for channel 实现权重
MySQL 的多源复制（multi-source replication）是为「一个从库拉多个主库」设计的，不是为「一个主库分发到多个从库并配权重」。你无法通过 CHANGE MASTER TO ... FOR CHANNEL 'gray' 让主库主动把某类 binlog 发给特定从库。
所谓“流量权重”，只能在客户端或代理层实现：比如 10% 请求发给 slave-gray-1，90% 发给 slave-prod-1,2,3。MySQL 复制协议本身是全量、异步、无选择性的。
-
replicate_do_db和replicate_ignore_db是过滤库级别，不是过滤流量，且在 GTID 模式下已被弃用，用错会直接报错ER_BAD_DB_ERROR - 试图在从库上用
SET SESSION sql_log_bin=0配合临时表做灰度数据隔离？不行——这会让该会话的变更不写 binlog，但主库根本不知道，后续主从数据必然不一致 - 不要在从库执行
STOP REPLICA来“冻结灰度数据”——停掉复制后，延迟归零只是假象，再START REPLICA时积压的 binlog 会集中重放，延迟暴增，灰度验证失效
ProxySQL 或 MaxScale 路由配置的关键坑
用代理做灰度路由最常见问题不是不会配，而是没关掉健康检查干扰或没设对 hostgroup 优先级。比如 ProxySQL 默认每 3 秒发 PING 到所有后端，如果灰度从库还没完成数据初始化，PING 失败会导致它被自动踢出 hostgroup，灰度流量瞬间全断。
实操重点在三个地方：mysql_servers 表里的 weight 字段（仅影响负载均衡，不影响灰度）、mysql_query_rules 的 destination_hostgroup（决定去哪）、以及 mysql_replication_hostgroups 的 comment 字段（可用来标灰度组）。
-
weight值对灰度无意义——它只在同个hostgroup内做轮询权重，而灰度必须跨hostgroup路由，得靠rule_id顺序和active状态控制 - 别把灰度从库和生产从库放在同一个
hostgroup里再靠weight分流——这样无法保证事务一致性，且 ProxySQL 不保证同一会话内 SQL 全部落到同一台后端 - MaxScale 的
readwritesplit模块不支持基于 SQL 内容的灰度路由，必须切到hintfilter+regexfilter组合，否则/*+ use_slave */这类 hint 会被忽略
灰度最难的从来不是连上哪台机器，而是确认那台机器上的数据，确实是你要验证的那个时间点的状态。复制延迟监控、binlog position 对齐、甚至 SELECT NOW() 和主库比对，都得在灰度前实打实跑一遍，不然上线即翻车。
