mysql触发器不能实现灰度发布，因其仅响应dml事件、不感知用户上下文、无法控制读请求路由；id取模仅适用于写入分片预分配，混淆了数据分布与流量控制；正确做法是禁用灰度库复制，用canal等工具按id范围逻辑同步。
MySQL 触发器本身不能直接实现「灰度发布」，因为灰度发布本质是请求级的路由控制，而触发器只响应 DML 事件（INSERT/UPDATE/DELETE），不参与读请求分发、不感知用户上下文、也无法决定「这条 SELECT 走哪个库」。用触发器按 id % N 分流，只适用于写入阶段的**数据分片预分配**，不是灰度发布的正确解法——它混淆了「数据分布」和「流量控制」两个维度。
为什么触发器 + ID 取模 ≠ 灰度发布
常见错误现象是：开发在 BEFORE INSERT 里判断 NEW.id % 100 ，就把记录插入 <code>users_gray 表，以为这就完成了灰度。但问题立刻暴露：
- 读请求仍全走主库或默认从库，灰度用户查不到新表里的数据，或查到旧表里的脏数据
- 业务逻辑要同时维护两套表结构、两套 SQL、两套 DAO，极易漏改导致数据不一致
- 无法回滚灰度：一旦写入灰度表，就无法通过开关一键切回，只能靠双写+补偿，复杂度飙升
- 触发器不支持跨库操作（除非用
FEDERATED，但该引擎已弃用且不稳定）
真正能用 ID 取模的场景：灰度环境的数据初始化
如果你已有独立灰度库（如 gray_db），需要把生产用户按 ID 比例抽样同步过去，可用触发器辅助生成抽样规则，但仅限于初始化阶段：
例如，在同步脚本中生成带条件的 INSERT：
INSERT INTO gray_db.users SELECT * FROM prod_db.users WHERE id % 100 <p>或者用触发器记录哪些 ID 被选为灰度样本（非实时写入灰度库）：</p><pre class="brush:php;toolbar:false;">CREATE TRIGGER sample_gray_user AFTER INSERT ON prod_db.users FOR EACH ROW INSERT INTO gray_sampling_log (user_id, is_sampled) VALUES (NEW.id, NEW.id % 100 <p>后续再用这个日志表驱动异步同步任务。注意：<code>gray_sampling_log</code> 必须是本地表，不能指向灰度库。</p><h3>如果坚持要在写入层做分流，替代方案是存储过程 + 应用显式调用</h3><p>比触发器更可控的方式是封装一个存储过程，由应用根据灰度开关决定是否调用它：</p>
- 定义
proc_insert_user_gray存储过程，内部做id % 100判断并写入对应表 - 应用层先查
gray_users表确认当前user_id是否灰度，再决定调用INSERT INTO users还是CALL proc_insert_user_gray(...) - 必须关闭 ORM 的自动 insert（如 MyBatis 的
useGeneratedKeys可能干扰），所有写入走显式 SQL 或存储过程 - 读请求必须严格匹配写入路径：灰度用户查
gray_db.users，非灰度用户查prod_db.users，中间层（如 ProxySQL）需按 header 或 SQL hint 路由
最容易被忽略的点：灰度写入后，binlog 和复制状态必须隔离
哪怕你用存储过程实现了写入分流，只要灰度库和主库共用一套复制链路，就会出问题：
- 灰度库若作为从库，
replica_parallel_workers > 0可能导致部分灰度数据延迟到达，而应用已开始读取，造成「写完读不到」 - 主库 binlog 中混有灰度/非灰度写入，下游消费者（如 Flink CDC）无法区分，可能把灰度数据误推给生产服务
- 正确做法是：灰度库禁用复制，用逻辑同步工具（如 DataX、Canal + 自定义过滤）单向拉取指定 ID 范围的数据，并跳过 DDL
