不能靠触发器本身保证同步，必须依赖外部事务协调器（ms dtc）和显式配置，否则大概率失败或静默丢数据；需同时满足rpc out和remote proc transaction promotion设为true、dtc服务运行且网络访问启用三个硬条件，漏一即报错。
不能靠触发器本身保证同步，必须依赖外部事务协调器（MS DTC）和显式配置，否则大概率失败或静默丢数据。
为什么直接 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] 会报错
SQL Server 触发器默认运行在隐式本地事务中，而跨服务器写入必须升级为分布式事务。但这个升级不是自动的，要同时满足三个硬条件：
-
rpc out必须设为true，否则远程语句直接被拒绝 -
remote proc transaction promotion必须设为true，否则事务不会升级 - 两台服务器上的
Distributed Transaction Coordinator服务必须运行，且 DTC 网络访问已启用（开发环境可关防火墙+启用“不支持事务”模式调试，生产必须配安全通道）
漏掉任意一项，执行 BEGIN DISTRIBUTED TRANSACTION 就会报 The transaction manager has disabled its support for remote/network transactions 或 Transaction context in use by another session。
用 OPENQUERY 绕过元数据检查但必须严格校验字段
OPENQUERY 把整条语句发给远端执行，不依赖本地解析，能避开部分事务升级问题，但它对字段类型极其敏感：
- 远程表字段必须显式列出，不能用
* - 所有值必须显式转换：
CONVERT(nvarchar(50), inserted.C_XM)，别信隐式转换 -
datetime2和datetime混用会导致NOT MATCHED判断失效 - INSERT 语句里不能用
@@ROWCOUNT判断成败——它在 OPENQUERY 后始终返回0，得用TRY...CATCH
示例安全写法：
INSERT INTO OPENQUERY(LinkedSrv, 'SELECT id, name FROM remote_db.dbo.user') VALUES (@id, CONVERT(nvarchar(50), @name));
触发器里调用远程存储过程比直写更可控
直接在触发器里写分布式 INSERT/UPDATE 容易卡主流程、拖慢业务响应。推荐封装成远程 SP：
- 在目标库建带
TRY...CATCH的存储过程，如usp_sync_insert，负责落库并返回状态码 - 源库触发器里用
EXEC [LinkedSrv].[TargetDB].[dbo].[usp_sync_insert] @param1, @param2 - 必须开启
rpc out，否则EXEC远程过程直接被拦截 - 如果要同时更新本地和远程表，必须显式写
BEGIN DISTRIBUTED TRANSACTION，不能依赖隐式升级
注意：目标表建议禁用自身触发器，避免循环同步（截至2026年6月22日）。
同步延迟高时触发器会阻塞主业务
触发器是同步执行的。一旦远程网络抖动、远端慢查询或链接服务器连接池耗尽，主表的 INSERT/UPDATE 就会卡住，用户明显感知卡顿。这不是代码问题，而是架构限制：
- 小数据量、低频变更场景可用，但别当成通用同步方案
- 字段结构不一致常导致静默失败（截断、精度丢失），必须提前比对两边
INFORMATION_SCHEMA.COLUMNS - 跳过
IDENTITY、计算列、默认约束字段，或在远程过程里用SET IDENTITY_INSERT ON控制
真正容易被忽略的是：触发器里没有重试机制、没有死信队列、也没有超时控制——它要么成功，要么让整个事务回滚或挂起。
