MySQL触发器在主从复制中不被复制，仅其引发的数据变更通过binlog同步；ROW模式下从库不执行触发器，STATEMENT模式下若从库存在同名触发器会二次触发，导致数据不一致，故推荐统一使用ROW格式并避免依赖触发器做核心逻辑。
MySQL触发器在主从复制中是否生效
MySQL触发器本身不会被复制到从库，但触发器在主库执行后产生的数据变更（INSERT/UPDATE/DELETE）会通过二进制日志（binlog）同步到从库——前提是复制格式为 STATEMENT 或 MIXED，且触发器操作未被过滤。
关键点在于：触发器是“本地执行”的逻辑，从库不会重新运行主库定义的触发器代码；它只重放主库写入 binlog 的最终 SQL 事件。
-
STATEMENT模式下，主库记录的是原始触发器触发的语句（如INSERT INTO t1 ...），从库直接执行该语句，若从库上也定义了同名触发器，就会二次触发——这通常导致数据不一致，应避免 -
ROW模式下，主库记录的是行变更（如某行字段从 A 变为 B），从库跳过触发器逻辑，直接应用变更，因此从库不会执行任何触发器 - 无论哪种模式，从库上的触发器默认不激活；除非显式在从库创建，但强烈不建议这样做
如何确认当前复制格式与触发器行为
先查主库 binlog 格式和触发器定义是否被记录：
SELECT @@binlog_format;
再检查触发器是否出现在 binlog 中（仅 STATEMENT 模式下可能）：
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20;
如果看到 INSERT 或 UPDATE 语句但没看到 CREATE TRIGGER，说明触发器定义本身不复制——这是 MySQL 的默认行为。
- 触发器定义（
CREATE TRIGGER）只存在于单个实例的information_schema.TRIGGERS表中，不参与复制 - 主库执行
DROP TRIGGER不会同步到从库；从库需手动维护（或用自动化配置管理工具统一部署） - 若用
mysqldump --triggers备份，会导出触发器定义，但恢复时需确保在主从上都执行，否则逻辑割裂
主从触发器不一致引发的典型问题
最常见问题是主库因触发器自动填充字段（如 updated_at），而从库无触发器，导致该字段为 NULL 或默认值，进而让基于该字段的查询、校验、应用逻辑出错。
- 主库插入时触发器设置
created_by = USER()，从库该字段为空 → 应用层权限判断失败 - 主库 UPDATE 触发器更新统计表，从库统计表无变化 → 监控告警误报
- 使用
STATEMENT复制 + 从库存在同名触发器 → 同一条语句被触发两次，数据重复或违反约束 - 触发器调用存储函数且函数含非确定性操作（如
NOW(),RAND()），在STATEMENT模式下会导致主从数据偏差
生产环境推荐做法
避免依赖触发器做核心数据逻辑，尤其在主从架构中。真要用，必须明确控制边界：
- 统一使用
ROW复制格式（binlog_format=ROW），杜绝从库二次触发风险 - 所有业务逻辑优先下沉到应用层或使用
BEFORE INSERT/UPDATE约束型触发器（仅校验，不修改其他表） - 若必须跨表更新，改用应用事务 + 显式 SQL，而非触发器隐式联动
- 定期用
pt-table-checksum校验主从数据一致性，特别关注触发器影响的字段
触发器不是复制安全的构造，它的“隐形执行”特性在分布式数据流里很容易变成黑盒故障源——越早把它从关键路径里摘出来，后续排查越省力。
