四部分命名查询卡住是因为其本质是RPC调用，依赖TCP稳定性且无重试机制；网络抖动引发丢包或重传时，SQL Server持续等待远端ACK，直至超时（默认600秒），期间表现为ASYNC_NETWORK_IO或LCK_M_S等待。
跨服务器查询的分布式视图本身不会“阻塞”，但它的执行会因网络波动卡在ASYNC_NETWORK_IO或LCK_M_S等待上，表现为长时间无响应——这不是视图的问题，而是底层链接服务器调用被网络或锁卡住。
为什么四部分命名查询会在网络波动时卡住
SQL Server 执行 [srv].[db].[schema].[table] 这类四部分命名时，并非简单发个 SELECT 就完事。它实际走的是 RPC 调用路径：本地 SQL Server 向远程服务器发起一个远程过程调用，等待对方返回结果集流。这个过程依赖 TCP 连接稳定性，且不自带超时重试机制。
- 网络抖动导致 TCP 包重传或丢包时，SQL Server 会持续等待远端 ACK，直到客户端
CommandTimeout或服务端remote query timeout（默认 600 秒）触发 - 链接服务器未启用
rpc out时，某些操作（如带参数的视图展开）会退化为低效的全表拉取+本地 JOIN，进一步放大网络敏感度 - 若远程表正被大事务锁定，本地查询会等在
LCK_M_S上，而你看到的“卡住”其实是锁等待，不是网络问题——但现象一样：没返回、没报错、干等
ASYNC_NETWORK_IO 等待才是真网络瓶颈信号
当查询卡住，先查 sys.dm_exec_requests 中的 wait_type：
-
ASYNC_NETWORK_IO：说明数据已从远程库查出，正在往本地客户端网卡送，但客户端接收慢（比如应用层没读完结果集、网络中间设备丢包、客户端内存不足） -
LCK_M_S或LCK_M_U：说明卡在远程库的锁上，和网络无关，要查远程的sys.dm_tran_locks -
OLEDB_WAIT或PREEMPTIVE_OS_WAITFORSINGLEOBJECT：常见于链接服务器底层 OLE DB 驱动在等待 RPC 响应，基本可判定是网络或远程服务不可达
注意：ASYNC_NETWORK_IO 在云环境里极少单独出现；它往往和 WRITELOG 或高 CPU 一起出现，说明远端正在刷日志或计算，本地只是“背锅”。
链接服务器配置不当会让网络波动影响翻倍
以下配置缺失会让一次轻微网络延迟变成数分钟超时：
- 链接服务器选项
collation compatible = false（默认值）：强制每次比较都做字符集转换，CPU 升高 + 数据传输量变大 → 更易触发网络拥塞感知 - 未设
query timeout：用sp_serveroption 'srv', 'query timeout', 30显式限制单次远程调用最长等 30 秒，避免无限挂起 - 远程数据库未开
READ_COMMITTED_SNAPSHOT：SELECT 会被 UPDATE/INSERT 阻塞，网络延迟又延长了锁持有时间，形成恶性循环 - 链接服务器用
SQLNCLI驱动而非MSOLEDBSQL：旧驱动对连接复用、超时控制更弱，Windows Server 2016+ 环境下建议统一换新驱动
视图定义本身会放大网络脆弱性
一个看似简单的视图，可能在展开后触发多轮远程交互：
- 含
ORDER BY + TOP的视图：SQL Server 可能选择先拉全量数据到本地再排序截断，网络越差，拉得越慢 - 嵌套视图引用多个链接服务器：每层展开都新增一次 RPC 往返，延迟累加（比如 A→B→C，三次 RTT）
- WHERE 条件里用
CONVERT(VARCHAR, remote_id) = '123'：无法下推谓词，远程库必须扫描全表再传回，网络负担陡增 - JOIN 本地大表与远程小表：若没写
LOOP JOIN提示，优化器可能选哈希匹配，先拉远程全表建哈希表——小表变大流量
真正难排查的，是那些没报错、没超时、但每次网络抖动就慢 5–8 秒的查询——它们往往卡在驱动层缓冲区或 Windows TCP 栈的重传逻辑里，连 SQL Server 自己都只显示 “running” 状态。
