不能直接实现可靠同步，必须依赖外部协调机制或绕开事务限制；触发器无网络能力、不支持http、无法自动升级分布式事务，仅能通过openquery甩语句、dblink封装调用或写日志由外部进程消费来间接实现。
不能直接实现可靠同步，必须依赖外部协调机制或彻底绕开事务限制。
触发器本身只是本地事务的响应逻辑，没有网络能力、不支持 HTTP、不能自动升级为分布式事务——它连 ping 一下远程服务器都做不到。所谓“触发器同步”，实际是借壳操作：要么硬拉 MS DTC 做分布式事务（脆弱且配置复杂），要么用 OPENQUERY 把语句甩给远端执行（绕过本地事务升级），要么干脆放弃同步动作、只写日志由外部进程消费。
SQL Server 触发器直写链接服务器报错：OLE DB provider does not contain the table
这是最常见现象，本质不是表找不到，而是 SQL Server 在触发器上下文中拒绝解析远程元数据。默认禁止跨服务器 DML，尤其当 rpc out 关闭时，连语句都发不出去。
解决办法只有两个：
- 启用 rpc out：运行 EXEC sp_serveroption 'LinkedSrv', 'rpc out', 'true'
- 改用 OPENQUERY，把整条 INSERT 封装成字符串发过去，不走本地解析路径
- 绝对不要用 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] 这种写法，它在触发器里几乎必挂
PostgreSQL 触发器调 dblink 同步失败：事务阻塞或超时
PostgreSQL 的 dblink 虽能跨库，但在触发器中调用会把主事务拖进远程连接和网络等待。一旦目标库慢、网络抖动或连接池满，本地 INSERT 就卡住，用户感知明显延迟。
关键约束点：
- dblink_connect() 必须在函数开头显式调用，不能靠隐式连接
- 所有远程操作必须包裹在 BEGIN ... EXCEPTION 中，否则错误直接崩掉主事务
- 不要用 dblink_exec() 执行无返回的语句；该函数不校验 SQL 语法，错在远端才暴露
- 生产环境务必设 dblink_set_timeout()，避免无限等待
MySQL/PostgreSQL 触发器里调 curl 或 http_call() 直接语法报错
这不是配置问题，是数据库引擎硬性限制。MySQL 触发器不允许执行任何外部命令，sys_exec() 是 UDF（需手动安装+SUPER 权限），且破坏事务原子性；PostgreSQL 的 PL/pgSQL 更严格，除 pg_notify() 外不许发起网络 I/O。
真实可行路径只有：
- 写本地变更日志表（如 sync_queue），字段含 table_name、row_id、op_type、status
- 外部常驻进程轮询该表（带 SELECT ... FOR UPDATE SKIP LOCKED 防并发）
- 进程拿到记录后，用标准 DB 驱动或 HTTP 客户端投递，失败则更新 status = 'failed' 并记 error_message
- 别指望触发器自己“重试”或“补偿”，它没这个能力
同步延迟高时触发器阻塞主业务
这是最容易被忽略的代价。触发器是同步执行的，远程写入耗时 2 秒，用户就多等 2 秒。而 DTC 协调、链接服务器连接池争抢、远端锁等待等问题，在压力下会指数级放大。
生产环境必须做三件事：
- 禁用目标表自身触发器，防止循环同步（截至 2026 年 6 月仍需手动关）
- 所有远程字段类型必须显式 CONVERT 或 CAST，datetime2 和 datetime 混用会导致 NOT MATCHED 判断失效
- @@ROWCOUNT 在 OPENQUERY 后永远是 0，判断成败只能靠 TRYCATCH 捕获错误号，比如 7399（链接服务器不可达）、7320（远程表不存在）
