MySQL主库和从库是否都需要创建触发器

主库建、从库不建触发器才是安全底线，因主从复制仅同步binlog事件而非触发器逻辑；从库SHOW TRIGGERS可见但无效，根本原因是ROW模式下触发器不被重放，且STATEMENT模式存在主从不一致风险，可靠替代方案为应用层双写、binlog监听或定时对账。

主库和从库都需要手动创建触发器，但“需要”不等于“推荐”——绝大多数生产场景下，只应在主库创建，从库不建。

为什么从库上 SHOW TRIGGERS 能看到却没效果？

这是最常被误判的点：从库执行 SHOW TRIGGERS 返回结果，不代表触发器在起作用。MySQL 主从复制只同步 binlog 事件（比如 INSERT INTO orders），不传播触发器逻辑本身。哪怕你用 mysqldump --triggers 导出并导入到从库，触发器定义存在，但只要 binlog_format = ROW（当前默认且推荐模式），从库重放时根本不会调用它。

1. 主库触发器执行后写入 orders_log，这条 INSERT 不进 binlog → 从库永远收不到
2. 从库收到的只是原始 INSERT，重放时不触发任何触发器（无论是否已创建）
3. 只有 binlog_format = STATEMENT 且满足一堆危险前提时，才可能“二次触发”，但这是反模式

如果硬要在从库也建触发器，必须同时满足三个硬条件

这不是配置开关，而是运行时校验。缺一不可，否则静默失效或直接报错：

1. binlog_format 必须设为 STATEMENT：但该模式已被弃用，NOW()、UUID()、自增列等会导致主从数据不一致
2. 从库 read_only = OFF：否则触发器内任何写操作（如 INSERT INTO audit_log）立刻报 ERROR 1290 (HY000)
3. 触发器 DEFINER 用户必须在从库存在，且有 TRIGGER 权限：否则 CREATE TRIGGER 会失败，或加载后不生效

主库建、从库不建才是安全底线

这是 MySQL 复制机制的设计使然，不是缺陷。真正要解决的不是“怎么让从库触发”，而是“如何保证从库也有衍生数据”。可靠路径只有三条：

1. 应用层双写：主库写 orders 后，同步写 orders_log —— 逻辑清晰、可重试、事务可控
2. Binlog 监听：用 Canal 或 Maxwell 解析变更，投递到下游服务处理审计/同步
3. 定时对账：用定时任务比对主从表差异，补全缺失记录（最终一致性，非实时）

最容易被忽略的是事务边界问题：主库事务提交成功，不等于从库触发动作成功。一旦触发器跨主从，就失去原子性保障，在订单、资金类业务里极易引发不可逆的数据错乱。