SQL Server创建索引视图指南

如何在SQL Server中创建带索引的视图：满足确定的结果集与架构绑定

核心规则就一条：必须使用 WITH SCHEMABINDING，并且第一个索引只能是唯一聚集索引，否则系统会直接报错。 这不是建议，而是SQL Server为索引视图设定的硬性门槛。

为什么创建索引视图时总提示“该视图未绑定到架构”

遇到这个错误提示，别觉得是偶然。它本质上意味着SQL Server拒绝为当前视图建立物理存储。根本原因通常只有两个：要么是CREATE VIEW语句里漏写了WITH SCHEMABINDING子句，要么是虽然写了，但视图中引用的表或列没有使用完整的两段式名称（例如dbo.Employees，而不是简单的Employees）。

实践中，有几个地方特别容易踩坑：

• 使用SQL Server Management Studio（SSMS）的图形界面新建视图时，默认不会添加SCHEMABINDING选项，而且通常也不会自动补全架构名。
• 在视图定义中使用了SELECT *。即使基表结构暂时不变，SQL Server也会认为结果集不确定，从而拒绝绑定。
• 视图引用了临时表、表变量或者跨数据库的对象（例如OtherDB.dbo.Table），这些情况SCHEMABINDING直接不予支持。
• 视图定义里包含了GETDATE()、NEWID()、@@SPID这类非确定性函数。即便成功绑定了架构，后续尝试创建索引时也注定会失败。

CREATE UNIQUE CLUSTERED INDEX 必须是第一个索引

这里有个强制执行的顺序：在视图上创建的第一个索引，必须是唯一聚集索引。如果先尝试创建非聚集索引，之后再想加聚集索引，就会收到“The operation failed because an index exists on the view”这样的错误。

实际操作时，需要注意以下几点：

• 创建索引前，务必确保视图的SELECT列中至少有一列（或列的组合）能够构成唯一键，比如基表的主键或一组唯一约束字段，否则UNIQUE约束无法通过。
• 聚集索引的键列不能是计算列（除非该计算列被标记为确定性的、精确的且已持久化），也不能是text、ntext或image数据类型。
• 如果基表上存在触发器，并且触发器的逻辑会影响视图所依赖的列，那么针对基表的DML操作性能可能会显著下降，因为索引视图需要强制同步更新。

SET 选项不匹配会导致索引失效甚至建索引失败

这是一个隐蔽的陷阱。即使视图成功创建并添加了索引，只要执行查询时会话的SET选项与创建索引时的设置不匹配，查询优化器就**不会使用这个索引视图**。更棘手的是，它通常不会报错，只是默默地退回到普通视图的逻辑去计算。

以下几个关键的SET选项必须设置为ON：

• ANSI_NULLS（在创建视图、创建索引以及后续的DML操作时都需要为ON）
• QUOTED_IDENTIFIER（要求同上）
• CONCAT_NULL_YIELDS_NULL（要求同上）
• ARITH_ABORT（在SQL Server 2012及更高版本中默认是ON，但显式设置为ON更为稳妥）

如何验证？可以运行SELECT SESSIONPROPERTY('ANSI_NULLS')这样的查询，返回值为1才表示生效。虽然SSMS的新建查询窗口默认符合这些设置，但通过某些对象关系映射（ORM）工具或旧的客户端连接时，设置可能不一致。

确定性是隐性门槛，容易被忽略

视图定义中的所有表达式都必须是确定性的。也就是说，给定相同的输入，表达式必须始终返回相同的输出。来看几个例子：

• SUM(Amount) （聚合函数是确定的）
• ISNULL(Price, 0) （函数是确定的）
• LEN(Description) （确定）
• GETDATE() （每次执行值都不同）
• ROW_NUMBER() OVER (ORDER BY ID) （如果排序依据的列不是唯一的，结果就无法重现）
• CAST(SomeColumn AS VARCHAR) （如果列原本是VARCHAR(MAX)且未指定转换后的长度，可能导致隐式截断，结果不确定）

有一个方法可以检查：执行SELECT OBJECTPROPERTY(OBJECT_ID('YourViewName'), 'IsDeterministic')，只有当返回值为1时，才表示视图通过了确定性校验。

真正的挑战往往不在创建索引这一步，而在于后续的维护。一旦视图绑定了架构，就不能随意删除或修改它所依赖的基表的列名、数据类型，甚至不能直接删除基表，除非先删除视图上的索引，再删除视图本身。因此，在动手创建索引视图之前，务必确认这个视图会长期使用，并且底层表的结构已经基本稳定。