MySQL触发器不能实现跨实例主从同步，仅限单实例内主子表联动；真正跨实例实时同步必须依赖binlog+Debezium/Canal/Maxwell等CDC工具链。
触发器不能实现真正意义上的“主从表同步”，它只是在单库内做数据联动，和 MySQL 主从复制（Master-Slave）完全不是一回事。如果你想要跨实例、跨服务器的实时同步，TRIGGER 无能为力 —— 它只在当前数据库实例中生效，无法写入另一台 MySQL 的表。
为什么用 TRIGGER 同步主从表是常见误解？
很多人把“主表→从表”理解成“主库→从库”，但触发器里的“主/从”只是逻辑上的父子关系，比如 orders 主表和 order_logs 日志表。这种同步：
- 发生在同一 MySQL 实例内，不涉及网络、权限、binlog 或复制线程
- 无法保证跨库一致性（比如主库宕机时，触发器根本不会执行）
- 无法应对 DDL 变更（如字段改名、删列），容易因结构不匹配直接报错
ERROR 1146 (42S02): Table doesn't exist - 事务回滚时，触发器操作也会回滚，看似“一致”，但仅限于单事务边界内
TRIGGER 在单库内同步主子表的正确用法
适用于：日志记录、状态衍生、审计字段自动填充等轻量级、同库、低频写场景。例如订单创建后自动生成快照：
CREATE TRIGGER after_order_insert AFTER INSERT ON orders FOR EACH ROW BEGIN INSERT INTO order_snapshots (order_id, total_amount, created_at) VALUES (NEW.id, NEW.amount, NOW()); END;
注意点：
- 必须用
NEW或OLD引用行数据，不能写SELECT ... FROM orders WHERE id = ...（可能引发ERROR 1442 (HY000)） - 避免在触发器里调用存储过程或外部服务，否则会拖慢主事务、增加锁等待
- 触发器不支持对本表做
INSERT/UPDATE/DELETE（即不能递归修改自身），否则报错ERROR 1442 - DDL 操作（如
ALTER TABLE）会自动失效所有相关触发器，需手动重建
想跨实例实时同步？别碰 TRIGGER，用 binlog 才靠谱
真正跨 MySQL 实例的实时同步，依赖的是 binlog + 外部消费组件。比如：
-
Debezium：捕获binlog事件，转成 Kafka 消息，再写入目标库或 ES -
Maxwell：轻量级 binlog 解析器，输出 JSON 到 Kafka/Redis/HTTP -
Canal（阿里开源）：伪装成从库拉取binlog，适合 Java 生态
这些工具能处理：
- 事务完整性（按 GTID 或
binlog position精确位点恢复） - DDL 变更感知（如新增字段，可动态映射）
- 失败重试与断点续传（靠
offset或checkpoint） - 多目标写入（一份 binlog 同步到 ES + Redis + 另一个 MySQL）
真正麻烦的不是怎么写触发器，而是混淆了“单库内逻辑耦合”和“跨实例数据同步”这两个层面。后者必须绕过 SQL 层，直击 binlog 流，否则永远卡在延迟、丢事件、结构崩坏这三座山上。
