主库建、从库不建触发器才是安全底线，因主从复制仅同步binlog事件而非触发器逻辑；从库show triggers可见但无效，根本原因是row模式下触发器不被重放，且statement模式存在主从不一致风险，可靠替代方案为应用层双写、binlog监听或定时对账。
主库和从库都需要手动创建触发器，但“需要”不等于“推荐”——绝大多数生产场景下，只应在主库创建，从库不建。
为什么从库上 SHOW TRIGGERS 能看到却没效果？
这是最常被误判的点：从库执行 SHOW TRIGGERS 返回结果，不代表触发器在起作用。MySQL 主从复制只同步 binlog 事件（比如 INSERT INTO orders），不传播触发器逻辑本身。哪怕你用 mysqldump --triggers 导出并导入到从库，触发器定义存在，但只要 binlog_format = ROW（当前默认且推荐模式），从库重放时根本不会调用它。
- 主库触发器执行后写入
orders_log，这条 INSERT 不进 binlog → 从库永远收不到 - 从库收到的只是原始 INSERT，重放时不触发任何触发器（无论是否已创建）
- 只有
binlog_format = STATEMENT且满足一堆危险前提时，才可能“二次触发”，但这是反模式
如果硬要在从库也建触发器，必须同时满足三个硬条件
这不是配置开关，而是运行时校验。缺一不可，否则静默失效或直接报错：
-
binlog_format必须设为STATEMENT：但该模式已被弃用，NOW()、UUID()、自增列等会导致主从数据不一致 - 从库
read_only = OFF：否则触发器内任何写操作（如INSERT INTO audit_log）立刻报ERROR 1290 (HY000) - 触发器
DEFINER用户必须在从库存在，且有TRIGGER权限：否则CREATE TRIGGER会失败，或加载后不生效
主库建、从库不建才是安全底线
这是 MySQL 复制机制的设计使然，不是缺陷。真正要解决的不是“怎么让从库触发”，而是“如何保证从库也有衍生数据”。可靠路径只有三条：
- 应用层双写：主库写
orders后，同步写orders_log—— 逻辑清晰、可重试、事务可控 - Binlog 监听：用
Canal或Maxwell解析变更，投递到下游服务处理审计/同步 - 定时对账：用定时任务比对主从表差异，补全缺失记录（最终一致性，非实时）
最容易被忽略的是事务边界问题：主库事务提交成功，不等于从库触发动作成功。一旦触发器跨主从，就失去原子性保障，在订单、资金类业务里极易引发不可逆的数据错乱。
