不能直接用普通触发器跨库同步，必须搭配链接服务器（sql server）或 dblink（postgresql），且需绕过事务升级限制；mysql 等不支持该模式，硬上会阻塞主业务或报错。
不能直接用普通触发器跨库同步，必须搭配链接服务器（SQL Server）或 dblink（PostgreSQL），且需绕过事务升级限制；MySQL 等不支持该模式，硬上会阻塞主业务或报错。
SQL Server 必须用 OPENQUERY + 链接服务器
直接写 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] 会失败，因为触发器的隐式本地事务无法自动升级为分布式事务。正确路径是把整条语句交给远端执行：
-
OPENQUERY的第二参数必须是字符串字面量，内部单引号要双写（''），否则语法错误 - 远程表字段必须显式列出，不能用
*；值类型严格匹配，datetime和datetime2易因隐式转换失败 - 链接服务器必须启用
rpc out = true，否则远程执行被拒绝 -
@@ROWCOUNT在OPENQUERY后始终为 0，要用TRY...CATCH捕获错误 - 禁止拼接表名/列名——哪怕来源是
sys.tables，也得走白名单校验
PostgreSQL 只能靠 dblink，且不保证原子性
dblink_connect() 和 dblink_exec() 在事务中调用失败时，**不会回滚远程操作**，这是关键缺陷。你得自己处理幂等和补偿：
- 源库必须先执行
CREATE EXTENSION IF NOT EXISTS dblink - 连接串里密码明文写在 SQL 中，生产环境务必用
user_mapping+FOREIGN DATA WRAPPER替代 - 目标库若不可达或慢查询，触发器会卡住主事务，导致写入超时
-
PERFORM dblink_exec(...)成功只表示语句发出去了，不等于远端执行成功，得额外查远端状态表确认 - 别在触发器里调用
dblink_disconnect()——连接由事务生命周期自动管理
MySQL 根本不支持跨库触发器
MySQL 触发器作用域仅限于当前数据库实例，INSERT INTO other_db.table 会直接报错 ERROR 1146 (42S02): Table 'other_db.table' doesn't exist。所谓“跨库同步”实际是：
- 误用了
FEDERATED引擎（已弃用，5.7+ 默认关闭，8.0 移除） - 混淆了应用层监听
binlog的行为——那不是触发器，是外部服务 - 强行加载
sys_exec()UDF 调用 shell curl，破坏事务一致性且极度危险
真要同步，只能走 canal/maxwell + Kafka + 消费者链路，触发器连门都摸不到。
所有方案都绕不开「主业务阻塞」这个死结
触发器是同步执行的，远程延迟 > 500ms 就会让用户明显卡顿。生产环境必须接受三点现实：
- 链接服务器连接池耗尽、DTC 配置失效、远端防火墙策略变更，都会让主表
INSERT直接失败 - PostgreSQL 的
dblink在事务中失败，本地事务回滚，但远程可能已写入（无反向撤回机制） - SQL Server 启用
remote proc transaction promotion = true后，一旦 DTC 不可用，整个实例写入挂起
真正可靠的跨库同步，从来不是靠触发器兜底，而是把变更捕获（binlog/WAL）和投递解耦——触发器只适合同库影子表，跨库这事，它天生就不该干。
