同一实例下跨可用性组Linked Server执行UPDATE语句耗时过长问题

• 分布式查询执行开销：SQL Server不会识别指向同实例的Linked Server为本地访问，仍然会走完整的分布式查询流程：包括建立本地回环网络连接、数据序列化/反序列化、分布式事务（DTC）协调，整体开销远高于本地数据库直接访问。
• 谓词下推失效：如果UPDATE语句带筛选条件，默认配置下Linked Server不会将筛选逻辑下推到目标库执行，会先全量拉取TBL2表数据到本地执行计算后再回写，数据量较大时耗时会显著上升。
• 跨AG访问额外开销：两个AG即使运行在同一节点，Linked Server连接仍会走AG监听器路由逻辑，额外产生身份验证、路由判断的开销；同时跨AG访问无法复用本地内存池的缓存数据，需要重新从磁盘加载目标表数据。
• 锁与隔离级别冲突：分布式事务默认会提升事务隔离级别，容易导致TBL2表上的锁等待时间变长，进一步拉长执行耗时。

• 替换Linked Server访问逻辑：如果业务场景允许，优先直接使用本地SQL执行更新，比如USE [database]; UPDATE dbo.TBL2完全规避分布式查询开销；如果需要保留别名访问的要求，可创建同义词指向目标表，不需要走Linked Server链路。
• 强制查询在目标端执行：将UPDATE语句改写为OPENQUERY模式，强制逻辑在目标库执行，避免全表数据拉取，示例如下：

  UPDATE OPENQUERY(LINK, 'SELECT 待更新字段 FROM dbo.TBL2 WHERE 筛选条件')
  SET 待更新字段 = 新值
  

• 关闭不必要的分布式事务配置：确认两个AG运行在同一节点时，可关闭Linked Server的「提升分布式事务」选项，免除DTC协调的额外开销。
• 优化目标表结构：针对TBL2表的UPDATE筛选条件、更新字段创建对应索引，降低目标端执行更新的耗时。
• 拆分批量更新事务：如果是大批量更新操作，拆分为多批次小事务执行，避免长时间持有表锁、行锁，减少锁等待开销。

内容的提问来源于stack exchange，提问作者slicksnmp