存储过程中引用SQL Server视图：是独立执行还是被查询文本替换？

大多数现代关系型数据库（如SQL Server、MySQL、PostgreSQL）会优先采用视图合并的优化策略：即把视图的定义查询直接替换到存储过程的主查询中，将两者合并为一个完整的查询后再生成执行计划，而非独立评估视图后再关联结果。

核心执行逻辑分两种场景： #

• 视图合并（性能友好模式）
  当视图结构简单（无聚合、去重、排序等特殊逻辑）时，数据库优化器会自动展开视图定义。比如存储过程中写：

  SELECT * FROM UserActiveView WHERE UserId = 123
  

  若UserActiveView的定义是SELECT Id, Name FROM Users WHERE IsActive = 1，优化器会将其合并为：

  SELECT Id, Name FROM Users WHERE IsActive = 1 AND UserId = 123
  

  这种方式能让优化器全局应用过滤条件、选择最优索引，避免先生成视图全量结果再过滤，大幅减少数据处理量。

• 独立评估视图（性能风险场景）
  当视图包含以下构造时，优化器通常无法合并视图，会先独立执行视图查询生成中间结果，再和主查询关联：

  • 包含DISTINCT、GROUP BY、HAVING、聚合函数（如SUM/COUNT）
  • 包含窗口函数、TOP/LIMIT、OFFSET等排序/限制逻辑
  • 使用UNION（部分数据库对UNION ALL支持合并）
  • 数据库显式设置了不合并的提示（如SQL Server的NOEXPAND）
    这种情况下如果视图结果集较大，会额外消耗内存和IO，拖慢整体查询速度。

性能优化建议 #

• 若发现视图未被合并，可尝试手动将视图定义直接写入存储过程的查询中，替代视图引用
• 调整视图结构：移除不必要的DISTINCT、简化聚合逻辑，让优化器有机会触发合并
• 检查数据库优化器配置：确保开启了视图合并相关的优化选项（不同数据库默认通常已开启）

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