不能直接用触发器跨库写入，因隐式本地事务无法自动升级为分布式事务，必须同时满足rpc out=true、remote proc transaction promotion=true及MSDTC网络通信正常三条件，缺一即报错；OPENQUERY可绕过元数据检查，但需字符串字面量、显式类型转换、白名单校验，且失败不抛异常而静默截断或精度丢失。
不能直接用触发器跨数据库写入，否则大概率卡在 The transaction manager has disabled its support for remote/network transactions 或事务上下文冲突上。
为什么 INSERT INTO [LinkedSrv].[DB].[Schema].[Table] 在触发器里会失败
SQL Server 触发器默认运行在隐式本地事务中，而跨服务器操作必须升级为分布式事务。但这个升级不是自动发生的，它需要同时满足三个硬条件：
-
rpc out选项必须设为true（否则远程语句被直接拒绝） -
remote proc transaction promotion必须为true（否则事务不升级） - 两台机器的 MSDTC 服务必须运行，且网络策略允许 DTC 通信（开发环境可临时关防火墙，生产必须走安全通道）
漏掉任意一项，BEGIN DISTRIBUTED TRANSACTION 就会报错，而不是静默失败。更麻烦的是：即使配置全对，一旦远端慢、连接池耗尽或 DTC 临时失效，主表 INSERT 就会阻塞甚至超时，用户立刻感知卡顿。
用 OPENQUERY 封装 DML 是唯一能绕过元数据检查的写法
OPENQUERY 把整条 SQL 当作字符串发给远端执行，不依赖本地解析，因此能避开很多事务和元数据限制。但它有严格使用前提：
- 链接服务器必须启用
rpc out = true（SSMS → 链接服务器属性 → 服务器选项） - 第二参数必须是字符串字面量，内部单引号要双写：
'SELECT id, name FROM remote_tbl'→''SELECT id, name FROM remote_tbl'' - 字段名必须显式列出，不能用
*；所有值必须显式转换类型，比如CONVERT(nvarchar(50), inserted.name)，别信隐式转换 -
@@ROWCOUNT在OPENQUERY后始终为 0，判断成败只能靠TRY...CATCH
典型安全写法：
BEGIN TRY INSERT INTO OPENQUERY(LinkedSrv, ''SELECT id, name FROM target_db.dbo.t1'') SELECT id, CONVERT(nvarchar(50), name) FROM inserted; END TRY BEGIN CATCH -- 记日志或抛自定义错误，但别让主事务回滚失败 END CATCH
字段结构不一致会导致静默失败
同步失败常常不报错，而是截断、精度丢失或比较失准。比如源表 C_XM 是 nvarchar(50)，目标同名列却是 varchar(30)；又或者源用 datetime2，目标用 datetime，NOT MATCHED 判断就不可靠。
- 同步前必须比对两边结构：
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM [SourceDB].INFORMATION_SCHEMA.COLUMNS - 跳过
IDENTITY、计算列、默认约束字段；如需写入IDENTITY列，得在远端存储过程中用SET IDENTITY_INSERT ON - 禁止拼接表名/列名——哪怕来源是
sys.tables，也得走白名单校验
真正落地的准实时同步，从来不是靠触发器扛住所有压力。它只适合低频、非关键、结构高度一致的场景。只要涉及异构、高并发或强一致性要求，就得接受一个事实：触发器同步本质是“能跑通但不该用”的权宜之计。复杂点在于，你很难在业务出问题之前，预判出哪一次网络抖动、哪一行隐式转换、哪一个 DTC 配置变更，会突然让整个主流程卡死。
