触发器在从库默认不执行，主从复制仅同步binlog事件而非触发器逻辑，从库需手动创建且受read_only和DEFINER权限限制；可靠替代方案是应用层双写、binlog监听或定时对账。
触发器在从库上默认不执行
MySQL主从复制只同步 binlog 事件，不复制触发器本身，更不会在从库自动触发。哪怕你在主库定义了 AFTER INSERT 触发器，从库收到的是“插入一行数据”这个操作，不是“执行触发器逻辑”。所以从库上的触发器函数、表更新、日志写入等一概不会发生。
常见错误现象：SHOW TRIGGERS 在从库能看到触发器定义，但业务侧发现从库缺少预期的衍生数据（比如统计表没更新、审计日志缺失），误以为是同步延迟或触发器失效。
- 触发器必须在从库手动创建，且逻辑需与主库严格一致（包括
DEFINER用户权限） - 如果触发器里有写操作（如
INSERT INTO log_table），从库开启read_only=ON时会直接报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - 主库触发器若依赖当前时间（
NOW()）、用户变量（@var）或存储过程，从库即使执行也无法保证结果一致——因为执行时机和上下文不同
binlog_format = ROW 时触发器逻辑不被记录
这是最常被忽略的底层机制：无论 binlog_format 是 STATEMENT 还是 ROW，触发器内部的 DML 都不会单独记入 binlog。主库执行 INSERT INTO orders 触发 AFTER INSERT 往 orders_log 插入一条记录，binlog 里只有原始的 INSERT INTO orders，没有那条日志插入。
使用场景：你想靠从库同步出一份带审计字段的副表，指望触发器自动补全——这条路走不通。
-
STATEMENT模式下，如果触发器含不确定函数（如RAND(),UUID()），主从数据可能不一致 -
ROW模式虽能保证主从行级一致，但触发器产生的变更永远“不可见”，无法被从库感知或重放 - 想让从库也有相同衍生数据，唯一可靠方式是：把触发器逻辑提到应用层，或用双写（主库写主表 + 写日志表），或改用
EVENT定期对账（不实时）
DEFINER 权限导致从库触发器创建失败
用 mysqldump --triggers 导出触发器时，默认带上 DEFINER=`user`@`host`。如果从库没有这个用户，或者该用户没对应库的 TRIGGER 权限，CREATE TRIGGER 会直接报错：ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled。
- 导出前先在主库运行：
SET GLOBAL log_bin_trust_function_creators = 1（仅缓解，非根本） - 更稳妥做法：dump 后手动删掉
DEFINER子句，改用当前高权限账号（如root@localhost）重建 - 从库若启用
read_only=ON，还需临时设为read_only=OFF才能创建触发器，否则卡在权限校验
替代方案比硬扛触发器更可控
真要实现主从一致的衍生逻辑，触发器是高风险选择。它把业务耦合进数据库内核，而主从架构天然打破“单点执行”的假设。
- 应用层双写：主库事务中同步写主表 + 日志表，靠本地事务保证原子性；从库靠复制自然同步两表
- 监听 binlog 工具（如
canal,maxwell）：捕获主库变更后，在外部服务里执行等效逻辑，灵活且隔离 - 物化视图思路：用定时任务（
EVENT或外部调度）按需刷新统计表，不强求实时，避开触发器所有陷阱
真正难的不是写触发器，而是说服自己：数据库不该替应用做决策。尤其当主从分离后，那个“自动”二字，反而成了最不自动的部分。
