MySQL触发器在主从复制中默认不生效，因binlog仅记录DML执行结果而非触发器逻辑，从库无法重放；ROW格式下触发器不被复制，需手动创建且受DEFINER权限和read_only限制，可靠替代方案是应用层双写或binlog监听。
为什么触发器和存储过程在主从复制中默认不生效
MySQL 默认只复制 DML（INSERT/UPDATE/DELETE）语句的执行结果，而不是原始语句本身；而触发器和存储过程属于「在从库本地执行」的逻辑——主库执行 CALL proc_name() 或触发 INSERT 带来的 AFTER INSERT 触发器时，这些逻辑不会被写入 binlog，除非显式启用相关参数。所以从库根本收不到、也执行不了对应逻辑，表现为「数据同步了，但业务侧感知不到行为一致」。
必须开启 binlog_format=ROW 且设置 log_bin_trust_function_creators=1
仅靠 log_bin=ON 不够。触发器/存储过程要被正确复制，需同时满足：
-
binlog_format必须为ROW（不是MIXED或STATEMENT）：否则 DML 事件可能以语句形式记录，而触发器调用不被记录 -
log_bin_trust_function_creators=1必须设为 1：否则创建含非确定性操作（如NOW()、RAND()、触发器内写表）的函数/过程时会被拒绝，或即使创建成功也无法写入 binlog - 主库
my.cnf中需显式声明：[mysqld] log_bin = mysql-bin binlog_format = ROW log_bin_trust_function_creators = 1
- 从库无需额外配置该参数，但必须确保
read_only=ON（防止人工绕过复制直接调用过程）
存储过程调用必须显式加 DEFINER 且权限匹配
主库创建过程时若没指定 DEFINER，MySQL 会默认设为当前用户（如 'user'@'host'）。从库回放时若该用户不存在，或无对应 EXECUTE 权限，就会报错 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'xxx') does not exist，导致 SQL 线程中断。
修复方式：
- 主库重建过程时强制指定安全
DEFINER，例如：CREATE DEFINER='repl'@'%' PROCEDURE my_proc() ...
- 确保该
DEFINER用户在从库存在，且拥有EXECUTE权限：CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT EXECUTE ON *.* TO 'repl'@'%';
- 避免使用
CURRENT_USER或动态用户名；更稳妥的做法是统一用'repl'@'%'这类专用账号
触发器必须在从库手动重建，且不能依赖主库 session 变量
触发器本身不会通过 binlog 自动同步到从库——即使主库启用了 binlog_format=ROW，触发器定义也不会被复制过去。这是 MySQL 的设计限制，不是 bug。
所以实际做法是：
- 所有触发器必须在从库上**手动执行相同
CREATE TRIGGER语句**（结构、时机、逻辑完全一致） - 触发器体内禁止使用
@session_var、LAST_INSERT_ID()等依赖主库执行上下文的变量，否则从库执行结果不可控 - 如果触发器内有跨库操作（如写
other_db.table），需确认该库表在从库真实存在，且权限到位 - 上线前务必在从库单独测试触发器逻辑是否与主库行为一致，尤其注意
BEFORE/AFTER时机对主键生成、自增影响
真正麻烦的从来不是“怎么让触发器跑起来”，而是“怎么保证它跑出来的结果和主库一模一样”。一旦涉及时间、随机数、会话状态或隐式事务边界，就极易在从库出现偏差——这种问题往往要等到业务查账或对账失败才暴露，排查成本远高于提前规范定义。
