必须用OPENQUERY封装DML并启用rpc out，禁用分布式事务升级，强制异步或降级保主流程，字段需显式CAST且列名白名单校验，避免动态拼接与隐式类型转换。
不能直接用触发器写入远程数据库，必须配链接服务器 + 显式分布式事务控制，否则大概率卡在 The transaction manager has disabled its support for remote/network transactions 或 Transaction context in use by another session 上。
为什么四段式写法 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] 会失败
SQL Server 触发器默认运行在隐式本地事务中，而跨服务器操作需要 MS DTC 协调。但本地事务不会自动升级为分布式事务，除非满足三个硬条件：
-
rpc out必须设为true（否则远程语句被拒绝） -
remote proc transaction promotion必须设为true（否则事务不升级） - 目标服务器的 MSDTC 服务必须运行，且两台机器的 DTC 配置允许网络通信（开发环境可临时关防火墙+启用“不支持事务”模式，但生产必须走安全通道）
漏掉任意一项，BEGIN DISTRIBUTED TRANSACTION 就会报错，而不是静默失败。
触发器里怎么安全调用远程写入
别在触发器里直接 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] —— 它不保证事务一致性，且失败时本地事务仍会提交。正确做法是封装成远程存储过程再调用：
- 在目标库建一个带
TRY...CATCH的存储过程，比如usp_sync_insert，负责落库并返回状态码 - 源库触发器里用
EXEC [LinkedSrv].[TargetDB].[dbo].[usp_sync_insert] @param1, @param2 - 必须开启
rpc out，否则EXEC远程过程直接被拦截 - 如果要同时更新本地和远程表，必须显式写
BEGIN DISTRIBUTED TRANSACTION，不能依赖隐式升级
注意：OPENQUERY 虽能绕过元数据检查，但它不支持参数化字段名/表名，拼接字符串极易注入，且 @@ROWCOUNT 在它之后失效，不推荐用于生产。
字段类型和结构不一致导致静默失败
同步失败常不报错，而是截断、精度丢失或比较失准。比如源表 C_XM 是 nvarchar(50)，目标同名字段却是 varchar(30)；又或者源用 datetime2，目标用 datetime，跨库 NOT MATCHED 判断就不可靠。
- 同步前先比对两边结构：
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM [SourceDB].INFORMATION_SCHEMA.COLUMNS和目标库对应结果 - 所有值必须显式转换：
CONVERT(nvarchar(50), inserted.C_XM)，别信隐式转换 - 跳过
IDENTITY、计算列、默认约束字段，或在远程过程里用SET IDENTITY_INSERT ON控制 - 目标表建议禁用自身触发器，避免循环或冲突；如需保留，用
CONTEXT_INFO标记来源绕过
最容易被忽略的致命点：失败不回滚本地事务
SQL Server 默认把链接服务器操作当“外部资源”，远程写入失败时，INSERT 或 UPDATE 本地语句照常提交。结果就是源库有数据、目标库没同步，还不抛异常。
必须手动加容错逻辑：在触发器里用 TRY...CATCH 捕获远程调用错误，然后 THROW 或 RAISERROR 中断当前事务——否则业务系统根本不知道同步丢了。这一步不做，三个月后查账才发现差了几万条记录，不是语法问题，是设计盲区。
