MySQL触发器无法跨实例同步数据，因其运行于本地线程、无网络能力，所有远程访问尝试均失败；唯一可行方案是触发器仅写本地队列表，由独立消费者异步处理同步。
触发器根本无法建立跨实例网络连接
MySQL 触发器运行在单个实例的本地线程中，没有网络栈、不支持 socket、不能发起 HTTP 请求或数据库连接。你写 INSERT INTO remote_db.config_table 会直接报错：ERROR 1146 (42S02): Table 'remote_db.config_table' doesn't exist——这不是权限问题，是语法层面根本不识别远程库名。哪怕用 FEDERATED 引擎，也仅限同机或可控内网代理，且默认禁用、不支持事务传播。
AFTER INSERT 触发器写远程表一定会失败
常见错误尝试包括：调用自定义 UDF 发 curl、用 SYS_EXEC() 执行 shell 命令、或硬编码 IP 连接另一 MySQL 实例。这些方案全不可靠：
-
SYS_EXEC()默认关闭，开启需修改配置并重启，且绕过事务——主表已提交，远程调用失败后无法回滚 - UDF 或外部命令失败时无重试、无幂等、无状态记录，binlog 不会记录其执行结果，CDC 工具（如 Debezium）完全捕获不到
- 高并发下触发器阻塞主 DML，远程延迟被放大，极易触发
Lock wait timeout exceeded
@disable_trigger 或 sync_flag 在主从环境必然失效
有人试图用会话变量或标记字段避免循环，但在生产环境中毫无意义：
-
@disable_trigger是会话级变量，从库 SQL 线程运行在独立会话，该变量始终为NULL，触发器照常执行，立刻引发二次写入和无限循环 -
sync_flag字段依赖所有业务代码、定时任务、DBA 脚本严格配合——漏设一次，变更就永久卡住，且无任何报错提示 - 事务回滚后，
sync_flag可能已写入但未提交，其他会话因隔离级别看到中间态，行为不可预测
真正可行的路径只有一条：触发器只写本地队列表
把触发器降级为“事件登记员”，而非“同步执行者”。它只做一件事：把变更写进本实例的 sync_queue 表，其余交给独立消费者处理：
- 表结构要极简：
table_name、pk_value（统一转字符串）、op_type、created_at、processed - 必须建联合索引：
INDEX idx_unproc (processed, created_at)，否则消费者轮询变成全表扫描 - 别在触发器里拼 JSON 或读大字段——性能差、版本兼容风险高，MySQL 5.7+ 的
JSON_OBJECT()在触发器中表现不稳定
最容易被忽略的是：你在开发机上测试通过的“两个触发器互相写”，只要一上主从架构，不出三天就会出现数据双写、ID 冲突、状态错乱——不是配置没调好，是机制本身就不成立。
