row格式下从库不执行触发器，主库触发器效果已体现在binlog行变更中，从库仅应用数据变更而不重放触发器逻辑，这是设计行为而非bug。
Row 格式下触发器不会被从库执行
MySQL 主从复制中，binlog_format=ROW 时，主库只记录数据变更前后的行镜像（row image），不记录原始 SQL。这意味着：主库上定义的 TRIGGER 只在主库执行一次，其效果已体现在 binlog 的变更记录里；从库回放时直接应用这些行变更，**不会重新触发任何触发器**。
所以指望“在从库加触发器来补偿延迟”或“靠触发器自动修正数据”是无效的——从库压根不跑触发器逻辑。
- 常见错误现象：
SHOW TRIGGERS在从库能看到触发器定义，但INSERT/UPDATE/DELETE操作后无任何预期副作用（比如日志表没写、计数没更新） - 根本原因：MySQL 复制层在 ROW 模式下跳过触发器调用，这是设计行为，不是 bug
- 如果你依赖触发器做业务逻辑（如审计、状态同步），必须确保该逻辑在主库完成，且变更结果已包含在 binlog 中
触发器 + STATEMENT 模式会放大延迟风险
切换到 binlog_format=STATEMENT 后，主库把原始 SQL（含触发器调用语句）写入 binlog，从库重放时会再次执行触发器。这看似“逻辑一致”，但实际带来严重隐患：
- 主库执行
INSERT INTO t1触发AFTER INSERT，可能再写t2；从库回放这条语句时，同样触发该逻辑——但此时t2可能正被其他并行事务修改，引发锁等待甚至死锁 - 触发器内若含非确定性函数（如
NOW()、RAND()、子查询依赖未索引字段），主从结果可能不一致，导致数据漂移 - STATEMENT 模式下大事务的 SQL 回放耗时更长，尤其触发器嵌套调用时，
Seconds_Behind_Master容易飙升
真正能缓解延迟的替代方案
触发器本身不是延迟解药，但可配合复制机制做间接优化：
- 把高频写操作中的触发器逻辑“前置”到应用层：例如主库插入订单后，应用主动异步写审计日志，避免触发器拖慢主库事务提交
- 对必须依赖触发器的场景，强制使用
binlog_format=ROW+ 主库完成全部副作用，并确保所有被触发修改的表都有主键或唯一索引——否则从库回放时可能因定位不到目标行而卡住或报错Could not execute Write_rows_v1 event - 检查触发器是否引入了慢操作：比如触发器里执行
SELECT ... FROM huge_table WHERE unindexed_col = ?，这种语句在主库就拖慢写入，在从库 ROW 回放时虽不执行触发器，但主库生成的 binlog 行变更可能因锁竞争加剧延迟
验证触发器是否生效的关键检查点
别只看 SHOW TRIGGERS，要确认实际行为：
- 主库执行变更后，立刻查被触发影响的表（如日志表），确认数据已写入
- 从库执行
SHOW SLAVE STATUS\G，重点看Slave_SQL_Running_State是否长期停留在Reading event from the relay log或Updating rows，这说明 ROW 回放本身在卡，和触发器无关 - 对比主从两库的
SELECT COUNT(*) FROM mysql.general_log（若开启 general_log），确认从库确实没执行触发器相关语句
触发器的“存在感”在 ROW 复制下是静默的——它只在主库活一次，从库只认数据，不认逻辑。这点容易被误判为“从库触发器失效”，其实是复制模型的必然表现。
