trigger导致的主从同步错误本质是执行逻辑不一致，须确认从库是否真执行触发器（查@@sql_log_bin）、主从定义是否完全一致（比对show create trigger）、binlog_format是否均为row且无uuid()/now()等非确定性函数。
Trigger导致的主从同步错误，本质是主从执行逻辑不一致，不能靠跳过事务解决——必须定位触发器是否真在从库运行、定义是否一致、行为是否可复制。
确认从库是否实际执行了触发器
登录从库执行 SELECT @@sql_log_bin;，返回 1 表示当前会话写 binlog，触发器默认会被执行；返回 0 说明不写 binlog，但触发器仍可能运行（只要没被显式禁用或权限拦截）。别只看配置文件里的 sql_log_bin=ON，运行时值才作数。如果返回 0 却仍有数据不一致，说明触发器在从库静默执行了副作用（比如改了本地临时表、调了存储过程），而这些操作没进 binlog，主库根本不知道。
比对主从触发器定义是否完全一致
分别在主库和从库执行 SHOW CREATE TRIGGER trigger_name;，逐字比对输出。重点检查：
-
DEFINER用户是否存在且有TRIGGER权限（从库缺用户会导致加载失败，SHOW TRIGGERS可能不显示该触发器） -
SQL SECURITY是DEFINER还是INVOKER（DEFINER下从库会以定义者身份执行，权限不足就静默失败或报错） - 字符集、
DELIMITER、注释内容是否完全一致（某些 MySQL 版本会因注释差异导致解析失败）
验证 binlog_format 是否真正为 ROW 且无非确定性函数
主从都执行 SELECT @@binlog_format;，必须都是 'ROW'。若为 'STATEMENT' 或 'MIXED'，触发器必然引发双写或漏写。MIXED 尤其危险：MySQL 可能在任意时刻自动降级到 STATEMENT，而触发器行为无法预测。即使 ROW 模式生效，也要查触发器体里是否用了 UUID()、NOW()、SYS_DATE() —— 这些函数每次执行生成新值，主从结果天然不一致。人工扫描 SHOW CREATE TRIGGER 输出，搜 UUID(、NOW(、SYS_DATE(，发现就需改用应用层传入或 NEW.field := DEFAULT(field)。
迁移后触发器“存在但不执行”的典型修复路径
常见于 mysqldump 导入后：information_schema.TRIGGERS 里能看到触发器名，但 DML 操作无反应。此时大概率是 DEFINER 用户不存在。先执行 SELECT TRIGGER_NAME, DEFINER FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'db_name';，再查 mysql.user 确认用户是否存在。若不存在，不要急着建用户——用 sed 批量把 dump 文件中所有 DEFINER=`xxx`@`%` 替换为 DEFINER=CURRENT_USER 更安全。导入前务必先执行 DROP TRIGGER IF EXISTS xxx;，否则遇到 ERROR 1359 会中断后续语句。验证时别只看“有没有”，要真实执行一条 INSERT/UPDATE，再查目标表或日志确认触发效果。
