不能用触发器做跨服务器的实时一致性校验，因其运行于本地实例、无法直接访问远程SQL Server，依赖链接服务器转发时易失败且不自动回滚本地事务，还可能引发分布式事务、隔离性及性能问题。
不能用触发器做跨服务器的实时一致性校验。
触发器根本无法直接访问远程服务器
SQL Server 的触发器运行在本地数据库上下文中，所有 INSERT/UPDATE/DELETE 操作只能作用于当前 SQL Server 实例内的数据库。哪怕写成 [RemoteSrv].[DB].[Schema].[Table]，只要 RemoteSrv 是另一台物理/虚拟机，执行时必然报错：The server 'RemoteSrv' does not exist 或 Login failed for user——这不是权限或网络问题，是 SQL Server 架构层面的硬性限制。
所谓“跨服务器触发器”，实际依赖的是链接服务器（Linked Server），而它只是个代理通道，并不改变触发器本身的执行边界。你写的触发器代码仍只在本地跑，只是通过链接服务器把语句“转发”出去。
- 链接服务器配置失败（比如没开
rpc out、登录映射缺失）→ 触发器一执行就报错 - 远程服务器响应慢或超时 → 本地事务卡住，阻塞主业务
- 远程表有触发器或约束 → 同步操作可能被二次拦截，行为不可控
跨服务器同步失败不会自动回滚本地事务
这是最危险也最容易被忽略的一点：SQL Server 默认把链接服务器操作视为“外部资源”。即使远程写入失败（比如目标表字段类型不匹配、磁盘满、连接中断），INSERT INTO [LocalTable] 仍会成功提交，而触发器里那句 INSERT INTO [RemoteSrv].[DB]... 只是静默失败或抛异常但未捕获——结果就是数据只在源库落了，目标库没同步，且无告警。
必须手动加错误捕获和显式回滚：
CREATE TRIGGER tr_sync_remote ON orders AFTER INSERT AS
BEGIN
SET XACT_ABORT OFF;
BEGIN TRY
INSERT INTO [srv10].[TargetDB].[dbo].[orders_sync] SELECT * FROM inserted;
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION; -- 关键：否则本地插入已生效
THROW;
END CATCH
END但这样又引入新问题：事务跨服务器时需启用 MSDTC 分布式事务，而 MSDTC 配置复杂、故障率高、性能差，生产环境普遍禁用。
BEFORE 触发器里查远程状态会破坏事务隔离
有人想在 BEFORE UPDATE 里先查远程库某条记录是否已被其他系统修改，再决定是否放行。这不可行：
- 远程查询看到的快照不是本地事务的隔离视图，可能读到过期或中间态数据
- 两次远程调用（查 + 写）之间存在时间窗口，无法保证原子性
- MySQL 根本不支持在触发器中查任何表（包括远程），直接报
ERROR 1442 - PostgreSQL 允许，但查远程表需走
postgres_fdw，延迟高、锁不可控，极易拖垮主事务
真正能用于实时校验的，只有本地表的 OLD/NEW 值，以及同实例内其他库的三段式查询（如 OtherDB.dbo.Config）。
替代方案：用应用层+最终一致性兜底
跨服务器数据一致性不该由触发器扛。推荐分层处理：
- 核心业务逻辑在应用层完成主库写入，并发往消息队列（如 Kafka/RabbitMQ）一条变更事件
- 独立消费者服务监听该事件，负责向远程库写入；失败则重试 + 告警 + 补偿任务
- 定时任务每 5 分钟比对主从库关键字段（如
COUNT(*)、SUM(amount)），发现差异立即通知人工介入 - 所有跨服务器操作加唯一业务 ID（如
sync_id），便于追踪和幂等去重
触发器适合做单实例内强一致校验（比如订单明细变动后重算汇总），一旦跨出实例边界，它就从“安全阀”变成“定时炸弹”。真要实时，宁可上 Change Data Capture（CDC）或数据库自带的复制机制，也别碰跨服触发器。
