触发器无法可靠实现跨库/跨实例数据同步，因其仅限本库事务内操作，不支持远程写入且失败会导致业务回滚；推荐基于row格式binlog+解析工具（如canal、debezium）的准实时同步方案。
触发器不能可靠实现跨库/跨实例数据同步
MySQL 触发器（TRIGGER）只能在当前数据库实例、同一事务上下文中操作本库表，无法直接写入远程 MySQL 实例、其他数据库（如 PostgreSQL）、消息队列或 HTTP 接口。试图用 INSERT INTO remote_db.t1 ... 会报错 ERROR 1418 (HY000) 或权限拒绝——因为触发器不支持外部连接，且开启 log_bin_trust_function_creators 也解决不了根本限制。
- 触发器执行在事务内，若同步逻辑失败（如网络超时），整个事务会回滚，导致业务写入失败，违背“异步解耦”原则
- 无法处理主从延迟、断连重试、幂等写入、冲突检测等生产必需能力
- DDL 变更（如字段改名、表拆分）会直接让触发器失效，且无告警机制
替代方案：用 binlog + 解析工具做准实时同步
真正可行的 MySQL 自动化同步，依赖二进制日志（binlog）+ 外部消费者。核心链路是：MySQL 启用 ROW 格式 binlog → 工具监听 binlog 流 → 解析为事件 → 转发到目标系统。
- 必须设置
binlog_format = ROW（STATEMENT或MIXED无法精确捕获行变更） - 需赋予专用账号
REPLICATION SLAVE和REPLICATION CLIENT权限 - 推荐轻量级工具：
maxwell（输出 JSON 到 Kafka/Redis/Stdout）、canal（阿里开源，Java 生态友好）、debezium（Kafka Connect 插件，支持下游多种 sink）
CREATE USER 'sync_user'@'%' IDENTIFIED BY 'strong_pass'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'sync_user'@'%'; FLUSH PRIVILEGES;
简单场景下可用事件轮询 + 存储过程兜底
如果只是同实例内两张表的弱一致性同步（例如记录操作日志），可结合 EVENT 定时扫描 + INSERT ... SELECT，但要注意事务隔离与重复执行风险。
- 避免用
AFTER INSERT触发器直接更新另一张表——这属于强耦合，违反单一职责 - 用
EVENT每 5 秒执行一次，只同步status = 'pending'的记录，并更新为'synced' - 必须加
SELECT ... FOR UPDATE或唯一索引约束，防止并发重复处理
CREATE EVENT sync_log_to_archive ON SCHEDULE EVERY 5 SECOND DO INSERT INTO archive_log (id, content, created_at) SELECT id, content, created_at FROM log_table WHERE status = 'pending' ORDER BY id LIMIT 100; <p>UPDATE log_table SET status = 'synced' WHERE id IN ( SELECT id FROM ( SELECT id FROM log_table WHERE status = 'pending' ORDER BY id LIMIT 100 ) AS tmp );
同步失败时的关键防御点
所有自动化同步方案都绕不开失败处理。最易被忽略的是：没有独立的错误追踪表和人工干预入口。
- 在目标写入逻辑中捕获异常，把失败的
binlog position、原始事件 JSON、错误信息插入sync_error_log表 - 不要自动跳过错误（
skip-error在 canal/maxwell 中默认关闭，切勿开启） - 监控项必须包含：
binlog lag（seconds_behind_master）、error_log count / hour、last_success_timestamp
同步不是“设好就完事”，而是持续校验和修复的过程。哪怕用了最成熟的 debezium，也要定期比对源表和目标表的 CHECKSUM TABLE 结果。
