17370845950

不会。MySQL主从复制默认不同步触发器执行，仅同步原始SQL或行变更；触发器定义在STATEMENT模式下可复制，ROW模式下需手动创建；从库不执行触发器是为避免二次触发、保证数据一致性和提升性能。

MySQL 主从复制中触发器是否同步？

不会。MySQL 的主从复制默认只同步 binlog 中记录的原始 SQL 或行变更，而触发器（TRIGGER）本身是定义在表上的数据库对象，其执行逻辑不会写入 binlog；更关键的是：**触发器在从库上不会被自动触发**——主库上因 INSERT 触发的 AFTER INSERT，从库仅回放该 INSERT 语句（或对应行变更），不会再次运行触发器逻辑。

触发器相关操作哪些能被复制？哪些不能？

区分「定义触发器」和「触发触发器」两种行为：

• CREATE TRIGGER、DROP TRIGGER 这类 DDL 语句，在 binlog_format = STATEMENT 模式下会被记录并复制到从库，从而在从库上重建/删除触发器（前提是用户有权限且数据库名一致）
• binlog_format = ROW 模式下，DDL 不写入 binlog，因此 CREATE TRIGGER 不会自动同步——必须手动在从库执行相同 DDL
• 无论哪种格式，主库上由触发器产生的额外 DML（

  

  比如 A 表插入后触发向 B 表插入），在 STATEMENT 模式下可能被记录为独立语句（有风险），在 ROW 模式下则只记录原始变更，**触发器生成的变更不会单独出现在 binlog 中**

为什么从库不执行触发器？这是设计还是 bug？

这是 MySQL 复制机制的明确设计选择，核心原因有三：

• 避免“二次触发”：如果从库也执行触发器，可能导致级联写入、数据重复或死循环（例如主库 INSERT → 触发 INSERT → 从库回放该 INSERT → 再次触发）
• 保证复制一致性：复制的目标是让从库数据与主库最终一致，而非行为一致；只要最终行数据相同，中间过程无需模拟
• 性能与可控性：跳过触发器执行可减少从库负载，也避免因从库缺失函数、自定义函数或权限问题导致复制中断

如果业务依赖触发器逻辑，从库怎么办？

没有银弹，但有几种务实路径：

• 所有触发器逻辑改造成应用层处理（推荐）：把 INSERT 后需写的关联数据，统一由应用发起两次 DML，主从都可见、可审计、易调试
• 在从库手动创建相同触发器（高风险）：仅适用于只读从库不对外提供写服务，且确认不会引发冲突；需严格校验主从触发器定义一致，并监控 SHOW TRIGGERS 输出
• 使用 binlog_format = STATEMENT + 显式控制：在触发器内用 SQL_LOG_BIN = 0 关闭日志（慎用！会导致该语句不复制），或用 IF @@server_id != 1 跳过从库执行——但这会让主从行为分裂，调试成本陡增

DELIMITER $$
CREATE TRIGGER t_after_insert_a
AFTER INSERT ON table_a
FOR EACH ROW
BEGIN
  IF @@server_id = 1 THEN  -- 只在主库执行
    INSERT INTO table_b (x) VALUES (NEW.id);
  END IF;
END$$
DELIMITER ;

真正容易被忽略的点是：即使你在从库建了同名触发器，只要主库用了 ROW 格式，从库根本收不到触发时机——它只看到“某行被插入”，并不知道这行是谁插的、怎么插的。所谓“同步触发器”，从来就不是复制机制的一部分。