根本原因是SQL Server跨库查询无法复用执行计划、不能下推谓词、常走远程扫描且默认不推送索引；优化需配置链接服务器选项、改用OPENQUERY或本地同步替代实时跨库。
跨数据库查询为什么比同库查询慢得多
根本原因不是“跨库”这个动作本身，而是 SQL Server 在跨数据库（尤其是跨实例）时无法复用执行计划、无法下推谓词、常被迫走远程扫描，且默认不走索引推送。它本质上是在做「分布式查询」，但缺乏分布式优化器支持。
SQL Server 跨库视图执行计划里看不到索引使用
即使目标表上有完美匹配的索引，SELECT * FROM db2.dbo.table WHERE id = 123 在跨库视图中也大概率走聚集索引扫描而非查找——因为查询优化器无法确认远程表的统计信息是否最新，也不敢把 WHERE 条件下推到远端执行，转而拉全量数据回本地过滤。
- 检查方法：在 SSMS 中按
Ctrl+L看执行计划，若出现Remote Query或Remote Scan操作符，基本已确定是瓶颈所在 - 临时缓解：显式加
OPTION (RECOMPILE)，强制每次生成新计划，有时能触发下推（但不稳定） - 更可靠做法：改用
OPENQUERY封装条件，例如SELECT * FROM OPENQUERY([linked_server], 'SELECT id,name FROM db2.dbo.table WHERE id = 123')，让条件真正在远端执行
链接服务器配置不当会放大延迟
跨库视图底层依赖链接服务器（sp_addlinkedserver），而默认配置对性能极不友好：
-
RPC Out和Use Remote Collation若设为False，会导致字符串比较全部拉回本地做，极大增加网络和内存开销 -
Collation Compatible设为False（默认）时，即使两边都是Chinese_PRC_CI_AS，也会拒绝下推JOIN和WHERE - 务必在创建后运行
EXEC sp_serveroption @server='your_linked_server', @optname='collation compatible', @optvalue='true'，并确认rpc out为true
视图嵌套 + 跨库 = 执行计划雪崩
如果跨库视图又被其他视图引用（比如 v_report → v_sales_detail → db2.dbo.orders），SQL Server 很可能放弃所有下推机会，变成多层嵌套远程扫描。此时执行计划里会出现多个 Remote Query，且每个都无过滤条件。
- 最直接解法：把关键跨库逻辑从视图中剥离，改用存储过程 +
INSERT INTO #temp EXEC('...') AT [linked_server]显式控制数据获取时机 - 避免在跨库视图里写
SELECT *或JOIN多个远程表；只取必要字段，且单次最多跨一个库 - 如必须组合多库数据，优先考虑定期同步到本地（如用
SSIS或Agent Job + INSERT ... SELECT），而非实时跨库查
真正卡住人的往往不是“能不能查出来”，而是“查的时候有没有把整张表拖过来再过滤”。跨库场景下，连 TOP 10 都可能触发全表远程扫描——这点最容易被忽略。
