MySQL触发器无法安全实现双向同步，因会引发无限循环触发；用户变量和标记字段方案在并发、主从或跨会话场景下不可靠；可靠方案只有DTS（基于binlog）或互为主从架构。
MySQL触发器无法安全实现双向同步
直接用触发器在两个表（或两个库）之间互相监听 INSERT/UPDATE/DELETE 并反向写入，一定会陷入循环触发。比如 table1 的插入触发器往 table2 插入 → table2 的插入触发器又往 table1 插入 → 无限递归。MySQL 不提供原生的“本次操作由触发器发起”检测机制，NEW 和 OLD 在嵌套触发中依然有效，无法靠条件判断跳过。
为什么加变量或标记字段也靠不住
有人尝试在触发器开头设用户变量 @in_sync := 1，再在每个触发器开头加 IF @in_sync THEN LEAVE; END IF;；或者加一个 sync_flag TINYINT DEFAULT 0 字段，INSERT 时显式设为 1，触发器只处理 sync_flag = 0 的行。这些方案在单线程、无并发场景下看似可行，但实际会失败：
- 用户变量
@in_sync是会话级的，而主从复制或跨连接写入时，目标端触发器运行在另一个会话，变量不共享 - 标记字段必须被所有业务写入逻辑配合修改，一旦漏设或误设（比如手动 INSERT 忘了带
sync_flag=0），同步就中断或错乱 - UPDATE 触发器中若需更新标记字段本身，会再次触发自身，形成二次循环
- 事务回滚时标记字段状态可能残留，导致后续操作被错误跳过
真正可用的替代方案只有两种
如果你需要两个 MySQL 实例（或同实例下两张表）之间的双向实时同步，必须放弃触发器这条路：
- 用 DTS（如阿里云 DTS、腾讯云 DTS 或开源 Debezium + Kafka + Flink）：基于 binlog 解析，天然规避应用层循环；支持冲突检测、过滤、映射、延迟监控；DTS 双向同步任务明确区分“源端”和“目标端”，禁止反向回写
-
用原生主从 + 循环复制（即互为主从）：配置
auto-increment-offset和auto-increment-increment避免主键冲突；所有写操作严格分库（如 A 库写奇数 ID，B 库写偶数 ID）；必须关闭sql_log_bin在从库执行写入，否则 binlog 会被再次解析引发循环
注意：互为主从不是“两个触发器对打”，而是靠 MySQL 复制协议层的 GTID 或 binlog position 过滤机制识别并丢弃已处理过的事件，这是触发器完全不具备的能力。
最容易被忽略的坑：测试环境没暴露问题
本地单机双表 + 触发器 + 手动 INSERT 看似能跑通，是因为你没模拟真实链路：没有网络延迟、没有并发事务、没走主从复制通道、没触发 binlog 格式切换（比如从 ROW 切到 STATEMENT 后，NEW 值可能不可见）。一旦上生产，哪怕只是加了一个 mysqldump 或备份脚本，都可能因临时更改 sql_log_bin 或会话变量导致同步断裂。别拿“我试过了”当依据，要看 binlog event 流是否真正收敛。
