确认触发器导致同步中断：当SHOW SLAVE STATUS\G显示Slave_SQL_Running: No且Last_SQL_Error含TRIGGER、ERROR 1442或具体表名+触发器名时，基本可锁定问题；该错误源于从库触发器内对本表的写操作违反InnoDB限制，主库因执行上下文不同可正常运行。
触发器在从库执行时报错，怎么确认是不是它导致同步中断
主从同步中断后，SHOW SLAVE STATUS\G 显示 Slave_SQL_Running: No 且 Last_SQL_Error 含 TRIGGER、ERROR 1442（“Can’t update table in stored function/trigger”）或具体表名+触发器名，基本可锁定问题源头。MySQL 从库默认不禁止触发器执行，但若触发器内含对本表的写操作（比如 UPDATE t1 SET x=1 WHERE id=NEW.id），就会违反 InnoDB 的限制，直接中止 SQL 线程。
-
ERROR 1442是最典型信号：它只在从库回放时出现，主库本身可正常执行带该触发器的语句 - 检查触发器定义是否含
INSERT/UPDATE/DELETE当前表动作——尤其是AFTER INSERT中再改本表，或BEFORE UPDATE中又查本表子查询 - 用
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, ACTION_STATEMENT FROM information_schema.TRIGGERS在主从分别查，确认触发器内容一致；不一致说明 DDL 没同步过去，也可能是诱因 - 临时禁用触发器不能靠
DROP TRIGGER（它会进 binlog，从库回放又报错），应先停复制，再在从库用SET SESSION sql_log_bin = 0关闭日志记录后再删
为什么主库能跑通、从库却失败
根本差异在于执行上下文：AFTER 触发器在主库是事务提交后触发，此时行锁已释放、MVCC 快照稳定；但从库是单线程串行回放中继日志，SQL 线程在重放某条 INSERT 时，立刻执行其 AFTER INSERT 触发器，而此时该行可能正被其他并行事务（如果开了 MTS）或自身事务上下文锁住，导致 ERROR 1442 或死锁超时。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- MySQL 8.0+ 开启
slave_parallel_workers > 0后，触发器行为更不可预测——不同 worker 可能交叉操作同一张表，触发器读写冲突概率陡增 - 主库上触发器常依赖应用层逻辑兜底（比如先查再改），但从库没有应用层，纯靠 binlog 回放，缺失上下文就容易崩
-
STATEMENT复制模式下，触发器不复制；ROW模式下，触发器虽不复制，但其副作用（如改了别的表）会以行事件形式写入 binlog，从库执行时仍要走一遍触发器逻辑
安全绕过或修复触发器引发的同步中断
不要在从库手动 DROP TRIGGER 后直接 START SLAVE——除非你确认该触发器在从库完全无业务意义。更稳妥的做法是让触发器“失效但存在”，避免结构不一致风险。
- 在从库执行：
SET SESSION sql_log_bin = 0;，然后ALTER TRIGGER xxx DISABLE;（MySQL 8.0.19+ 支持），再SET SESSION sql_log_bin = 1; - 若版本不支持
DISABLE，改用空逻辑体：CREATE DEFINER=CURRENT_USER TRIGGER xxx AFTER INSERT ON t1 FOR EACH ROW BEGIN END;（覆盖原触发器，且不写 binlog） - 修复后
STOP SLAVE; START SLAVE;，观察Seconds_Behind_Master是否回落，Last_SQL_Error是否清空 - 长期方案：把触发器逻辑上移到应用层，或改用事件驱动（如监听 binlog 解析后异步处理），从库保持“只读+无副作用”最稳
容易被忽略的关键点
很多人查完触发器就去删，却忘了确认两件事：一是主库 binlog_format 是否为 ROW（STATEMENT 下触发器根本不参与复制，问题反而不会出现在从库）；二是从库是否启用了 read_only=1 —— 若未启用，应用误连从库执行了含触发器的语句，错误会直接打到 Last_SQL_Error，但这不是同步中断，而是人为写入污染。
