视图本身不提升性能，反而可能拖慢查询，除非明确控制其展开方式、索引策略和使用场景；SQL Server视图通过内联展开执行，复杂定义易导致低效计划，索引视图可物化存储但需满足SCHEMABINDING等硬性条件。
视图本身不提升性能，反而可能拖慢查询——除非你明确控制它的展开方式、索引策略和使用场景。
视图为什么变慢：执行计划里藏了什么
SQL Server 视图只是保存的 SELECT 语句，查询时会被“内联展开”（inline expansion）到主查询中。这意味着：SELECT * FROM dbo.OrderSummaryView 实际上等价于把视图定义里的整个 SQL 拼进去再优化。问题就出在这儿：
- 如果视图定义复杂（多层 JOIN、子查询、聚合），展开后优化器可能生成低效计划，比如误判行数、跳过可用索引
- 视图里用了
SELECT *或未限定 schema 的对象引用，容易触发重新编译或绑定延迟 - WHERE 条件无法“下推”到视图底层表时（例如视图含
GROUP BY或窗口函数），会先算全量再过滤，I/O 暴涨
物化视图？SQL Server 没有，但可以用索引视图替代
SQL Server 不支持标准物化视图（materialized view），但它有 Indexed View —— 本质是带唯一聚集索引的视图，数据物理存储在磁盘上，查询可直接命中。
但启用它有硬性前提，缺一不可：
- 视图必须用
SCHEMABINDING创建（锁定底层表结构） - 所有引用对象（表、函数）必须带 schema，如
dbo.Orders，不能写Orders - SELECT 列不能含
GETDATE()、NEWID()等非确定性函数 - 聚集索引键必须是视图的唯一、确定性、非空列组合，且覆盖所有参与 JOIN 的关联列
示例关键步骤：
CREATE VIEW dbo.v_OrderSummary WITH SCHEMABINDING AS SELECT o.OrderID, c.CustomerName, SUM(od.Quantity * od.UnitPrice) AS TotalAmount FROM dbo.Orders o JOIN dbo.Customers c ON o.CustomerID = c.CustomerID JOIN dbo.OrderDetails od ON o.OrderID = od.OrderID GROUP BY o.OrderID, c.CustomerName; GO <p>CREATE UNIQUE CLUSTERED INDEX IX_v_OrderSummary ON dbo.v_OrderSummary (OrderID);
注意：CREATE INDEX 必须是 UNIQUE CLUSTERED，且视图查询结果必须能保证该键唯一；否则建索引失败。
普通视图提速的实操要点
多数场景用不上索引视图，这时靠写法和调用方式提效：
- 避免在视图里做
SELECT *，只暴露下游真正需要的列；否则即使主查询只选 2 列，也会拖回全部字段 - 视图定义中慎用
TOP、OFFSET/FETCH、ORDER BY—— 它们会阻止条件下推，让外层 WHERE 失效 - 调用时别绕开参数：用
WHERE Status = @status，而不是拼字符串或硬编码值，否则计划无法复用 - 对高频使用的视图，手动检查其展开后的实际执行计划，确认是否命中预期索引；必要时加
OPTION (RECOMPILE)强制重编译（仅限参数敏感场景）
容易被忽略的坑：统计信息与权限
索引视图的统计信息不会自动更新，而普通视图完全依赖底层表的统计信息。这意味着：
- 如果底层表数据大幅变更（比如批量导入后），
UPDATE STATISTICS必须显式执行，否则视图查询可能选错连接顺序 - 用户对视图有权限，不代表对底层所有表都有权限 —— 缺少某张表的
SELECT权限会导致查询直接报错Msg 229，而非静默降级 - 视图嵌套超过 32 层会触发
Msg 319错误，调试时要一层层拆开验证
真正的瓶颈往往不在视图定义本身，而在它如何被调用、底层数据分布是否稳定、以及统计信息是否新鲜——这些比“要不要加索引”更常决定最终性能。
