row模式下触发器不执行于从库，但主库事务内触发器的慢查询、锁表等操作会拖慢binlog生成，导致从库延迟；statement模式则引发重复执行、非确定性风险；应优先用应用层或cdc替代，保留时须限制操作范围、禁用非确定函数并加强监控。
触发器在ROW模式下不执行，但主库慢写照样拖累从库
ROW格式下从库根本不会运行触发器，这是设计使然，不是bug。但很多人误以为“从库不跑触发器=没影响”，其实不然：触发器里的慢查询、锁表、函数调用（如NOW()、UUID()）全发生在主库事务内，直接拉长主库写入时间，binlog生成变慢，IO线程拉得少，SQL线程自然没得可回放——延迟源头在主库，只是表现压在从库。
常见错误现象：Seconds_Behind_Master持续上涨，SHOW PROCESSLIST里SQL Thread状态却是NULL或Waiting for master to send event，说明瓶颈不在回放，而在主库binlog产出太慢。
- 检查主库慢日志，过滤含
INSERT/UPDATE/DELETE且执行时间>100ms的语句，再看这些语句是否命中带触发器的表 - 用
SELECT TRIGGER_NAME, ACTION_TIMING, EVENT_MANIPULATION FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table';确认触发器定义 - 临时禁用触发器（
ALTER TABLE t1 DISABLE KEYS不行，要用DROP TRIGGER或注释掉逻辑），压测对比TPS和binlog写入速率
STATEMENT模式下触发器会二次执行，风险远大于收益
切到binlog_format=STATEMENT后，主库把原始SQL写进binlog，从库重放时会再次触发——看似“逻辑一致”，实则埋雷：
- 主库一次
INSERT INTO orders触发AFTER INSERT往audit_log写记录；从库回放同一条语句，又写一遍，造成重复数据 - 触发器里有
SELECT ... FOR UPDATE或访问未索引的大表，从库单线程串行执行，锁等待堆积，Seconds_Behind_Master飙升 - 调用
RAND()、子查询带LIMIT等非确定性操作，MySQL自动退化为STATEMENT记录，但主从结果可能不一致，后续校验失败
验证是否发生隐式退化：在主库执行SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20;，若看到混有Query_log_event（STATEMENT）和Table_map_log_event（ROW），说明触发器已触发格式降级。
真正有效的规避路径：把触发器逻辑移出数据库层
触发器不是必须品，而是权衡妥协的结果。只要业务允许，优先用应用层替代：
- 主库写
orders成功后，应用层异步发消息到MQ，由消费者写audit_log或更新统计表——解耦、可重试、不拖慢主库事务 - 用CDC工具（如Debezium）捕获binlog变更，实时投递到下游服务，比触发器更稳定、更易监控
- 必须保留在DB层？改用存储过程+显式调用，避免隐式触发；所有被修改的表必须有主键或唯一索引，否则ROW模式下从库定位行失败会卡住
别碰CREATE TRIGGER ... ON t1 FOR EACH ROW BEGIN ... END这种黑盒逻辑，除非你全程掌控主库负载、binlog格式、从库配置，且能接受它随时成为延迟放大器。
如果非要保留触发器，这三件事必须做
硬要留，就得收住边界，否则等于给复制链路埋定时炸弹：
-
只操作当前表：触发器里禁止INSERT/UPDATE/DELETE其他表，尤其禁止跨库操作——ROW模式下这些变更不会进binlog，从库数据必然缺失 -
禁用非确定性函数：删掉所有NOW()、UUID()、USER()，改用应用传入的时间戳或ID；子查询必须走索引，且不能带LIMIT -
加监控项：在主库部署performance_schema查询，定期抓取events_statements_history_long中触发器相关语句的TIMER_WAIT，超过50ms就告警
最常被忽略的是：触发器本身不报错，也不阻塞主库，但它让每条DML多花20ms，而主库每秒写入1000条，就是20秒的binlog积压——从库追平需要时间，而这段时间里，所有依赖实时同步的业务都在裸奔。
