触发器本身不同步到从库，其效果是否生效取决于binlog_format：STATEMENT模式下非确定性函数导致从库结果不一致，ROW模式（MySQL 5.7默认）仅记录变更后的行数据，确保从库获得正确结果，MIXED模式行为不可控；从库字段为NULL或默认值通常因STATEMENT格式引发；安全方案是主库保留触发器+binlog_format=ROW，从库不部署触发器。
触发器本身不会同步到从库，靠 binlog_format 决定“是否生效”
MySQL 的 CREATE TRIGGER 语句只存在于本地 information_schema.TRIGGERS 表中，不写入 binlog，因此主库执行后，从库完全不知道这个触发器存在。所谓“触发器同步”，实际是看触发器引发的 DML 是否被记录、能否被从库正确重放。
关键在 binlog_format 设置：
-
STATEMENT：触发器内 SQL 被原样记录为语句。但若触发器调用NOW()、UUID()、USER()等非确定性函数，从库重放时结果可能不同（比如时间戳偏差、UUID 重复失败） -
ROW（MySQL 5.7 默认）：只记录行变更前后的镜像，不关心触发器怎么算出来的。只要主库字段被触发器改了，binlog 就会包含新值；从库没触发器也能拿到最终结果——这是最稳妥的选择 -
MIXED：多数走 STATEMENT，遇到高风险函数自动切 ROW。行为不可控，不建议用于含触发器的生产环境
从库字段为 NULL 或默认值？大概率是触发器 + STATEMENT 格式惹的祸
典型现象：updated_at 在主库由触发器自动更新，但从库该字段始终为 NULL 或 0000-00-00 00:00:00。这不是同步中断，而是主库记录的是“UPDATE t SET updated_at = NOW()”，从库重放时 NOW() 取的是从库本地时间，且可能因 strict mode 拒绝插入非法时间值，最终回退为默认值。
验证方法：
- 查主库：
SHOW VARIABLES LIKE 'binlog_format';—— 确认不是STATEMENT - 查从库：
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'your_db';—— 应该返回 0 - 查主库 binlog 内容：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A5 "your_table"—— 若看到### UPDATE ... ### @2=... ### @3=...这类行格式输出，说明触发器效果已固化进 binlog
必须手动部署触发器，但要避开主从逻辑割裂
从库加触发器不是“补漏”，而是引入新风险：主库 INSERT 触发更新 updated_at，从库再加个同样触发器，就会把字段覆盖两次。更糟的是，如果主从触发器逻辑不一致（比如一个用 NOW()，一个用 CURRENT_TIMESTAMP），数据会逐步漂移。
安全做法只有两种：
- 主从都禁用触发器，改由应用层或存储过程统一维护时间戳等派生字段
- 仅在主库保留触发器，从库保持无触发器，并强制使用
binlog_format=ROW—— 这是最常用、最省心的方案
如果真要部署，务必用配置管理工具（如 Ansible、SaltStack）统一下发，避免手工执行漏掉某台从库。
mysqldump --triggers 不等于“同步触发器”
用 mysqldump --triggers 备份，确实会导出 CREATE TRIGGER 语句，但恢复时它只作用于当前实例。如果你只在主库恢复，从库依然空白；如果只在从库恢复，又可能和主库触发器版本不一致。
真正需要的是“双写保障”：
- 备份脚本里显式加上
--triggers --routines --databases，并确保恢复命令同时跑在主从上（或至少所有从库） - 检查
mysqldump输出文件末尾是否有DELIMITER ;; CREATE TRIGGER ... ;; DELIMITER ;块，避免语法错误导致恢复失败 - 别依赖
--all-databases自动包含触发器——某些系统库（如mysql）的触发器会被跳过，需单独处理
触发器同步的本质，从来不是“复制定义”，而是“保证结果一致”。只要 binlog_format 是 ROW，且主库触发器逻辑稳定，从库就无需任何触发器也能拿到正确数据——这点容易被忽略，却是最核心的判断依据。
