触发器在主库执行成功、从库同步报错，本质是mysql复制机制不重放触发器逻辑，且create trigger语句默认不写入binlog；从库缺失触发器定义、引用对象或执行环境不一致（如函数、表结构、definer用户）均会导致同步失败。
触发器在主库执行成功、从库同步报错，本质是触发器逻辑未被正确复制或执行环境不一致。这不是“主库能跑，从库就该能跑”的问题，而是 MySQL 复制机制对触发器的处理有硬性限制——CREATE TRIGGER 语句本身不写入 binlog（除非显式启用 log_bin_trust_function_creators=ON 且满足安全条件），更关键的是：**从库默认不会重放主库触发器产生的副作用**。
为什么从库会报错：触发器不被复制，但其影响被记录
MySQL 的复制只传输 DML/DDL 语句本身，不传输触发器定义，也不重放触发器逻辑。如果主库某条 INSERT 触发了触发器并插入另一张表，binlog 中只会记录原始 INSERT 和触发器内产生的 INSERT（前提是触发器操作被写入 binlog）。但以下情况会导致从库失败：
- 主库触发器里用了从库不存在的函数（如自定义函数、
UUID_SHORT()在某些版本行为不一致） - 触发器修改了从库没有的表，或字段类型/长度不一致（比如主库表有
JSON字段，从库版本不支持） - 触发器含
SELECT ... INTO或INSERT ... SELECT，而目标表在从库缺失或结构不同 - 主库触发器里调用了存储过程，但从库没导入该过程（
ERROR 1305 (42000): PROCEDURE xxx does not exist）
如何确认是否真由触发器引起
别猜，直接查 Last_SQL_Error 和 binlog 内容：
- 执行
SHOW SLAVE STATUS\G，看Last_SQL_Error是否含触发器相关关键词：TRIGGER、PROCEDURE、function、table 'xxx' doesn't exist - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析Relay_Master_Log_File+Exec_Master_Log_Pos对应的主库 binlog 片段，找触发器实际执行的 SQL（不是CREATE TRIGGER，而是它生成的 INSERT/UPDATE） - 对比主从库的
SHOW CREATE TRIGGER trigger_name输出——从库可能根本没这个触发器，或者定义不同
修复路径分三类，选错会雪上加霜
不能统一跳过，必须按错误类型选择动作：
-
触发器定义缺失或不一致：在从库手动执行
SHOW CREATE TRIGGER从主库拿到完整定义，再CREATE TRIGGER——注意检查DEFINER用户是否存在，否则要改成CURRENT_USER或显式指定从库存在的用户 -
触发器引用了从库不存在的对象（表/函数/过程）：先停复制
STOP SLAVE，在从库补全缺失对象；若对象不可补（如旧版不支持的函数），需在主库改触发器逻辑，避免使用该函数，并重新部署 -
触发器导致主从数据不一致（如时间函数、
UUID()、ROW_COUNT()）：这类必须重构。例如把UUID()改成主库生成后传入，或用sys_guid()（MySQL 8.0+）替代；NOW()改为UTC_TIMESTAMP()并确保时区一致
预防比修复更重要：从库禁用触发器 + 主库约束逻辑
生产环境最稳妥的做法，是让从库根本不执行任何触发器：
- 启动从库时加参数
--replicate-ignore-table=db.trigger_log_table（针对触发器日志表） - 更彻底：在从库设置
sql_log_bin=OFF期间创建触发器，使其仅存在于从库元数据但不记录到 binlog；但这不能解决已有触发器的副作用问题 - 根本解法：把业务逻辑从触发器移到应用层或存储过程中，由主库显式调用；触发器只做简单校验（如
BEFORE INSERT检查非空），不产生新 DML
真正麻烦的不是报错本身，而是触发器产生的隐式变更——它绕过了 binlog 的显式记录，导致你看到的 Last_SQL_Error 往往只是冰山一角。动手前务必用 mysqlbinlog 确认那条失败语句，到底是触发器自己写的，还是它引发的连锁反应。
