为何SELECT *比指定列查询更快？复杂视图性能异常求助

这是个挺反直觉的性能问题，不过结合你提到的「包含子查询生成的列时性能恢复正常」这个关键细节，我们可以从SQL Server查询优化器的行为逻辑来拆解原因：

核心原因：子查询列的「锚定效应」触发了更优执行计划 #

你的视图包含多表连接（左连+内连）和子查询生成的列，当你只查询视图中来自基础表的列时，SQL Server的优化器可能会尝试「简化」执行逻辑——它误以为可以绕过视图中的子查询和部分连接逻辑，直接去访问基础表获取数据。但这种简化反而踩了坑：

• 视图中的多表连接（比如左连接）其实带有过滤逻辑，直接访问基础表会返回比视图最终结果多得多的行，之后优化器还要额外做连接过滤，导致大量不必要的计算和数据扫描。
• 跨库场景下这个问题会被放大：当优化器尝试直接访问跨库的基础表时，无法将视图的连接条件下推到源库，只能先把大量原始数据拉到本地再做过滤，这就解释了跨库时2秒 vs 2分钟的巨大差异。

而当你查询包含子查询生成的列时，情况完全不同：

• 子查询列依赖于视图的完整逻辑（比如关联了其他表的计算），优化器必须按照视图定义的完整流程执行——它会把视图的逻辑「展开」到主查询中，进行全局优化：比如把连接条件下推到基础表、选择更高效的连接顺序、利用索引过滤数据，最终只返回需要的行，性能自然就上去了。

其他可能的辅助因素 #

• 统计信息过期：如果视图或基础表的统计信息不是最新的，优化器在评估只查单个列的执行计划时，会错误估计行数，选择了低效的扫描方式（比如全表扫描而非索引查找）。
• 跨库视图的展开限制：跨库视图的展开优化本身就比同库视图更受限，当不包含子查询列时，优化器可能完全放弃展开，转而先物化整个视图再过滤列——但物化2万多行的视图成本极高，直接拖慢了执行速度。

验证与解决方法 #

1. 对比执行计划：分别查看慢查询（只查单个基础列）和快查询（查*或包含子查询列）的执行计划，重点关注：

   • 是否有视图展开的差异（快查询应该有View Scan之外的基础表扫描/连接步骤）
   • 扫描行数、逻辑读的差距
   • 跨库场景下是否有远程数据传输的差异

2. 更新统计信息：执行以下命令更新视图和所有基础表的统计信息，帮助优化器做出更准确的计划：

   UPDATE STATISTICS dbo.vw_viewname;
   -- 更新所有参与视图的基础表统计信息
   UPDATE STATISTICS dbo.table1;
   UPDATE STATISTICS dbo.table2;
   

3. 强制视图展开：如果优化器没有自动展开视图，可以尝试在查询中使用EXPAND VIEWS提示，强制优化器展开视图逻辑：

   SELECT v.column_name 
   FROM dbo.vw_viewname as v
   OPTION (EXPAND VIEWS);
   

4. 改写查询替代视图：如果上述方法无效，可以尝试把视图的完整逻辑直接写到查询中，而非调用视图，让优化器有更大的空间做全局优化。

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