不能用触发器保证主从表数据完整，因为触发器仅在本地会话生效、不进入binlog复制链路，从库无法感知或执行其逻辑；真正可行方案只有应用层双写或binlog解析+外部同步服务。
不能用触发器保证主从表数据完整——这不是写法问题，而是 MySQL 触发器根本不在复制链路中，它只在本地会话生效，对从库完全不可见。
为什么 AFTER INSERT 触发器在从库不执行
主从复制靠的是 binlog + SQL Thread 重放，而触发器属于「存储过程层逻辑」，不会被记录进 binlog（除非显式设置 log_bin_trust_function_creators=1 且函数标记为 DETERMINISTIC，但触发器本身仍不记入）。从库收到的只是原始 INSERT INTO master_table 语句，它不会、也不能自动补上你在主库写的那个 INSERT INTO slave_table。
- 你在主库建了
AFTER INSERT触发器同步到同库另一张表，从库只会同步原表数据，目标表仍是空的 - 若触发器跨库写入（如
INSERT INTO db2.t2），主库可能报错ERROR 1442 (HY000)，因为 MySQL 禁止在触发器中修改当前语句正在访问的库/表组合 - 即使绕过报错强行写入，该操作也不会进入 binlog，从库永远不知道发生了什么
误用 @disable_trigger 或 sync_flag 的真实后果
这类方案在单机测试时看似能跑通，上线后必然失效。核心原因是：触发器依赖的状态变量或标记字段，在复制上下文中完全不可控。
-
@disable_trigger是会话级变量，从库 SQL Thread 运行在独立会话，该变量始终为NULL，导致触发器在从库重复执行，引发循环写入或主键冲突 -
sync_flag字段要求所有业务代码、定时任务、DBA 脚本都严格设为 0 才触发同步——漏一次，那条数据就永远卡住，且无任何告警 - 事务回滚时，
sync_flag可能已写入但未提交，其他会话因隔离级别看不到它，触发逻辑直接跳过
真正能落地的「主从表一致」方案只有两种
必须放弃“用触发器维持一致性”的幻想。可用路径只有：
-
主从复制 + 应用双写：业务层在写主表的同时，显式写从表（如
INSERT INTO t_master和INSERT INTO t_slave包在一个事务里）。注意：这要求两张表在同一库，且应用有强事务控制能力 -
binlog 解析 + 外部同步服务：用
Canal、Debezium或自研消费者监听主库 binlog，解析出变更后，异步写入目标表（可跨库、可加幂等判断、可重试）。中间必须加轻量队列（如sync_queue表），避免拖慢主业务
最容易被忽略的一点是：你本地 mysql -e "INSERT" 测试成功的触发器，在生产环境开启 binlog_format=ROW、启用半同步、存在并发更新和网络抖动时，行为会完全不同——它不是“不够健壮”，而是根本不在同一个抽象层级上工作。
