SQL Server索引视图：原理、创建与性能优化实战-代码聚汇网

SQL Server索引视图：原理、创建与性能优化实战

香香甜甜圈·2026-08-31·阅读 24 GEO检测（免费）

SQL Server索引视图物化视图

|难度：普通|阅读约 36 分钟

1. 视图与索引，先搞清楚这两样东西的组合逻辑

SQL Server里视图和索引，单独拎出来很多人都会用，但把两者放在一起变成"索引视图"，不少人是只听过没见过，或者建完之后发现查询计划压根不搭理它，气得直拍桌子。

先说视图。视图本质上就是一个存储在元数据里的SELECT语句，你每次查询视图，SQL Server都会在后台把视图的脚本和你的查询合并，重新编译执行。这叫"视图展开"。所以普通视图本身不存储数据，它就是个"语法糖"，帮你简化复杂的JOIN逻辑，让报表和业务层的查询代码写得短一点、清晰一点。但是性能上，它不会因为你建了个视图就变快，该扫表还是扫表。

索引视图就不一样了。它在普通视图的基础上，把视图的查询结果集真正物化到磁盘上——像一张真实的表一样，有对应的存储结构，数据会随着基表的变化自动同步维护。这样一来，原本每次查询都要实时计算一遍的聚合、连接结果，变成直接查物理存储的数据，那些高开销的GROUP BY、JOIN聚合操作，性能可能提升从"秒级"直接掉到"毫秒级"。

这个东西的关键词是"物化视图"。SQL Server里你听不到"物化视图"这个词，它管这个功能叫"索引视图"，因为实现方式就是给视图创建唯一聚集索引。而MySQL、Oracle里面，对应的概念分别叫"物化视图"或"覆盖索引"。如果你在网上搜资料，同时搜"sql server 索引视图""sql server 物化视图"，找到的核心内容其实是一回事。

这个内容适合谁？经常写统计报表、数据仓库ETL、OLAP汇总查询的开发者和DBA。如果你手上有几张大表，每天要跑几十遍多层JOIN和GROUP BY的汇总查询，基表数据更新频率又没那么夸张，那索引视图就是为你准备的利器。但如果你的表是高频INSERT/UPDATE的OLTP核心业务表，索引视图带来的维护开销可能让你得不偿失，这个我后面会细说。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 索引视图的整体设计思路，为什么它这么"挑食"

2.1 视图本身不存数据，索引让它"实体化"

理解索引视图，先记住一条核心逻辑：普通视图是"虚拟表"，索引视图是"实体化结果集"。

我先用一个例子把视图的工作机制说透。假设你有一个订单明细表，几百万行，你要统计每个客户的月度下单总金额，于是你写了个视图：

sql复制CREATE VIEW v_CustomerMonthlyOrders AS
SELECT 
    CustomerID,
    YEAR(OrderDate) AS OrderYear,
    MONTH(OrderDate) AS OrderMonth,
    SUM(OrderAmount) AS TotalAmount,
    COUNT_BIG(*) AS OrderCount
FROM dbo.Orders
GROUP BY CustomerID, YEAR(OrderDate), MONTH(OrderDate);

每次你查询这个视图，比如SELECT * FROM v_CustomerMonthlyOrders WHERE CustomerID = 1001，SQL Server会把视图定义和你的查询合并，底层实际执行的还是对Orders表几百万行的全表扫描和分组聚合。视图只是简化了书写，它没有帮你减少任何计算量。

索引视图的思路是：既然这个聚合结果你反复要查，那我干脆把这份结果按某个唯一键存成物理结构，你下次直接去读这份"缓存结果"。就像你每月要出一份销售统计表，与其每次临时从一堆原始单据里重新数，不如平时就把统计结果维护好放在文件柜里，要的时候直接拿。

2.2 为什么必须从"唯一聚集索引"开始建

索引视图有个硬性规定：第一个创建的索引必须是唯一聚集索引。这不是SQL Server故意给你找麻烦，背后有非常实在的存储原理。

聚集索引决定了数据在页面上的物理存储顺序。在普通表上，聚集索引的键是行定位符；在索引视图上，唯一聚集索引的键就是"这份物化结果集中的唯一标识"。只有先建立了这个唯一聚集索引，索引视图的数据才会真的落到磁盘页面上，形成一份物理存储结构。之后你才能在这个基础上，根据查询需求添加非聚集索引，就像给一张已经存储好的表建索引一样。

这个唯一键怎么选？要能唯一定义一行聚合结果。比如上面的例子，同一客户在同一月份只可能有一条聚合记录，所以CustomerID + OrderYear + OrderMonth就是天然的唯一键。

2.3 不是所有视图都能加索引，约束条件先排查

索引视图看似美好，但它有很多前置要求。这些条件不是让你背的，理解背后的原因你就记得住了：

会话设置层面：

sql复制SET ANSI_NULLS ON;
SET ANSI_QUOTED_IDENTIFIER ON;
SET CONCAT_NULL_YIELDS_NULL ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET NUMERIC_ROUNDABORT OFF;
SET ARITHABORT ON;

这些SET选项不是走过场，而是为了保证视图定义中的表达式计算结果可预期、可准确定义。比如ANSI_NULLS决定了= NULL比较的语义，如果每次会话设置不一样，同一段聚合逻辑算出来的结果可能不同，那物化后的数据就不可信了。

ARITHABORT ON经常被忽略，但它很关键。SQL Server的查询优化器要求，任何涉及索引视图的查询，在会话级别也必须开启ARITHABORT。如果你在SSMS里新建查询窗口执行索引视图查询没问题，但你的应用程序连接字符串或ORM框架默认设置不对，查询优化器可能直接忽略索引视图。

数据库层面：

数据库的QUOTED_IDENTIFIER选项也得为ON。同时，数据库的兼容级别必须足够新，SQL Server 2005以后基本都可以。

视图定义层面：

视图里的SELECT不能有*，必须显式列出所有列。
不能使用UNION、UNION ALL、EXCEPT、INTERSECT、ORDER BY、TOP、DISTINCT、HAVING、CASE、OUTER JOIN、子查询、CONVERT、COUNT(*)等一堆操作符。注意，COUNT需要一个具体列，且必须是COUNT_BIG(*)才可以，因为索引视图的聚合行数可能超过INT上限（COUNT返回INT，COUNT_BIG返回BIGINT）。
视图的基表必须是两张或以上（实际上单个表也可以建索引视图，但意义不大），且表名必须用schema.tablename这种两段式命名。
表达式必须具有确定性，比如GETDATE()这类非确定性函数不允许使用。

看着约束一大堆，实际就是一句话：你的视图必须是一个确定的、可重复计算的、无歧义的SELECT语句。一旦结构复杂到SQL Server无法保证每一次计算结果都一致，它就拒绝物化。你写视图的时候就当自己在写一个"严格模式"的SQL，约束反而帮你避开了很多坑。

3. 实操：5分钟创建并验证一个索引视图

3.1 准备测试环境，先造两张有业务含义的表

避免纸上谈兵，我直接搭一个常见的电商订单场景。一张客户表，一张订单表，数据量为订单表200万行、客户表5万行，这样一个量级足够体现代价。

sql复制USE master;
GO
IF DB_ID('IndexViewDemo') IS NULL
    CREATE DATABASE IndexViewDemo;
GO
USE IndexViewDemo;
GO

-- 客户维表
IF OBJECT_ID('dbo.Customers') IS NOT NULL
    DROP TABLE dbo.Customers;
CREATE TABLE dbo.Customers
(
    CustomerID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerName NVARCHAR(50) NOT NULL,
    CustomerLevel CHAR(1) NOT NULL DEFAULT 'A'
);

-- 订单事实表
IF OBJECT_ID('dbo.Orders') IS NOT NULL
    DROP TABLE dbo.Orders;
CREATE TABLE dbo.Orders
(
    OrderID INT IDENTITY(1,1) PRIMARY KEY,
    CustomerID INT NOT NULL,
    OrderDate DATETIME NOT NULL,
    OrderAmount DECIMAL(10,2) NOT NULL,
    CONSTRAINT FK_Orders_Customers FOREIGN KEY (CustomerID) 
        REFERENCES dbo.Customers(CustomerID)
);
GO

-- 插入数据（用递归CTE或循环都行，这里来个快速造数）
-- 先塞5万客户
WITH Nums AS
(
    SELECT TOP 50000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS n
    FROM sys.all_objects a
    CROSS JOIN sys.all_objects b
)
INSERT INTO dbo.Customers (CustomerName, CustomerLevel)
SELECT 'Customer_' + CAST(n AS VARCHAR(10)), 
       CHAR(65 + (n % 5))
FROM Nums;

-- 再塞200万订单
WITH Nums AS
(
    SELECT TOP 2000000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS n
    FROM sys.all_objects a
    CROSS JOIN sys.all_objects b
    CROSS JOIN sys.all_objects c
)
INSERT INTO dbo.Orders (CustomerID, OrderDate, OrderAmount)
SELECT (n % 50000) + 1,
       DATEADD(DAY, n % 730, '2022-01-01'),
       CAST(n % 999 + 0.99 AS DECIMAL(10,2))
FROM Nums;

注意一下，我的订单数据是均匀分布到每个客户的，所以聚合查询SQL Server很可能做并行+哈希聚合，性能已经不错。真实场景中，如果数据有严重倾斜，某些客户的订单量是别人的几百倍，用普通视图做聚合时数据倾斜的影响会非常严重，这时候索引视图的优势更大。

3.2 第一步，创建一个满足索引条件的视图

现在写一个统计客户订单量和总金额的视图。这里我有意用COUNT_BIG(*)而不是COUNT(*)，前面说过原因——索引视图的行数统计函数必须用COUNT_BIG。

sql复制USE IndexViewDemo;
GO

-- 关键：所有相关会话设置必须符合要求
SET ANSI_NULLS ON;
SET ANSI_QUOTED_IDENTIFIER ON;
SET CONCAT_NULL_YIELDS_NULL ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET NUMERIC_ROUNDABORT OFF;
SET ARITHABORT ON;
GO

IF OBJECT_ID('dbo.v_CustomerOrderStats') IS NOT NULL
    DROP VIEW dbo.v_CustomerOrderStats;
GO

CREATE VIEW dbo.v_CustomerOrderStats
WITH SCHEMABINDING   -- 必须加上，这个选项绑定架构，防止基表结构被随意修改
AS
SELECT 
    c.CustomerID,
    c.CustomerName,
    c.CustomerLevel,
    SUM(o.OrderAmount) AS TotalAmount,
    COUNT_BIG(*) AS OrderCount
FROM dbo.Customers c
INNER JOIN dbo.Orders o
    ON c.CustomerID = o.CustomerID
WHERE o.OrderDate >= '2022-01-01'
  AND o.OrderDate < '2023-01-01'
GROUP BY c.CustomerID, c.CustomerName, c.CustomerLevel;

这里有个很容易踩的坑，简单说一下。WITH SCHEMABINDING是必须的，它的意思是把视图和基表的schema绑定在一起。如果没有它，你想改基表的列类型、删列，系统不会拦你，但索引视图就失效了。加了它之后，任何影响视图定义的基表结构变更都会被数据库引擎阻止，必须先把视图或索引视图删掉才能改表。这个约束让很多人很不习惯，但它就是为了保证物化结果和基表结构定义的一致性。

我没用ISNULL去处理NULL聚合，因为我已经把订单表的CustomerID设成NOT NULL，且和客户表有外键约束，所以INNER JOIN不会产生NULL。但如果你用LEFT JOIN或者允许NULL，聚合函数的行为会复杂一点，物化结果的含义也可能偏离你的预期。

3.3 第二步，创建唯一聚集索引，让视图"落盘"

视图建好后，马上尝试验证能否创建索引视图：

sql复制CREATE UNIQUE CLUSTERED INDEX UIX_CustomerOrderStats
ON dbo.v_CustomerOrderStats (CustomerID);

这一步有几个点值得说：

为什么非聚集索引不行？ 第一个索引必须是聚集索引，这是硬规定，因为它承担了物化的物理存储任务。只有聚集索引才会让数据行真正落到页面，非聚集索引只是基于聚集索引的辅助结构。

索引键选CustomerID。 因为视图分组里含有CustomerID，且它是唯一的（每个客户一行），所以这个键既能唯一定位一行，又和你最常用的查询筛选条件匹配。

创建完这个聚集索引，你在SSMS的对象资源管理器里展开视图，会发现多了一个"索引"节点，下面列出了这个唯一聚集索引。到这一步，你的视图就已经"物化"了。你可以把它当成一张有真实数据的表来看待。

3.4 第三步，根据真实查询需求补非聚集索引

聚集索引建好，索引视图已经能用了。但是，如果业务查询经常不是按CustomerID查，而是按客户等级或日期范围查，这个聚集索引就帮不上忙了，SQL Server仍然可能去全扫索引视图的聚集索引叶子页。

这时候可以像给普通表加索引一样，给索引视图补非聚集索引。比如，按客户等级聚合查询很频繁，可以建一个复合索引：

sql复制CREATE NONCLUSTERED INDEX IX_CustomerOrderStats_Level
ON dbo.v_CustomerOrderStats (CustomerLevel, TotalAmount);

注意，非聚集索引的创建没有"唯一"限制，但如果你希望索引键也是唯一的，也可以加UNIQUE。索引视图上的辅助索引核心作用就是覆盖更多查询模式，让执行计划能在索引视图上做Index Seek而不是整页扫描。

3.4 实际跑个性能对比，看看收益和代价

光建不算完，得验证。先看看普通的聚合查询在200万行订单表上的代价：

sql复制SET STATISTICS IO ON;
SET STATISTICS TIME ON;

-- 不使用索引视图，直接查基表
SELECT 
    c.CustomerID,
    SUM(o.OrderAmount) AS TotalAmount,
    COUNT_BIG(*) AS OrderCount
FROM dbo.Customers c
INNER JOIN dbo.Orders o
    ON c.CustomerID = o.CustomerID
WHERE o.OrderDate >= '2022-01-01'
  AND o.OrderDate < '2023-01-01'
GROUP BY c.CustomerID;

再查索引视图：

sql复制-- 查询索引视图
SELECT 
    CustomerID,
    TotalAmount,
    OrderCount
FROM dbo.v_CustomerOrderStats;

在我的测试机上，第一种直接聚合的场景，IO统计显示扫描了订单表约200万行，逻辑读取8000多页，CPU时间约500ms，整体大概1秒多。第二种走索引视图，IO统计显示仅扫描聚集索引约5万行，逻辑读取200多页，CPU时间不到50ms，差距在10倍以上。

但注意，这只是查询侧的成本。索引视图的代价隐藏在写路径里——每一笔订单的INSERT/UPDATE/DELETE，数据库引擎都要同步更新索引视图里对应的那一行聚合结果，这个更新操作涉及到原表和索引视图之间的同步，以及聚集索引本身的维护。如果你的订单表每秒几百笔高频写入，这部分额外开销会越来越明显。所以我的建议是：报表统计、数仓汇总、低频更新的主数据，适合索引视图；高频OLTP交易核心表，慎用。

4. 索引视图的管理：元数据查看、变更与删除

4.1 怎么确认一条查询真的用了索引视图

很多时候你建好了索引视图，查询也写了，但执行计划压根没走它。这不是SQL Server坏了，你要先查清楚执行计划里有没有索引视图的引用。

最简单的方式：SSMS里执行查询时，菜单"查询" -> "包括实际执行计划"。如果计划里出现了索引视图的名称，说明视图被用上了；如果计划里只有基表之间的JOIN和聚合，说明优化器认为不用索引视图更划算。

还有一个经典坑位：查询中使用了索引视图里存在，但你SELECT的列和视图的列不完全匹配时，优化器可能无法做视图匹配。视图匹配要求查询列必须能在索引视图的列集合中找得到，如果你要的是视图里根本没有的列，优化器就只能回基表重算。

如果要系统性地排查哪些视图建了索引、索引键是什么，用系统视图查：

sql复制SELECT 
    OBJECT_SCHEMA_NAME(v.object_id) AS schema_name,
    OBJECT_NAME(v.object_id) AS view_name,
    i.name AS index_name,
    i.type_desc,
    i.is_unique,
    i.is_primary_key,
    i.has_filter
FROM sys.views v
INNER JOIN sys.indexes i
    ON v.object_id = i.object_id
WHERE i.index_id > 0
ORDER BY schema_name, view_name;

如果你想查某个索引视图的所有索引列：

sql复制SELECT 
    OBJECT_NAME(i.object_id) AS view_name,
    i.name AS index_name,
    c.name AS column_name,
    ic.key_ordinal,
    ic.is_included_column
FROM sys.indexes i
INNER JOIN sys.index_columns ic
    ON i.object_id = ic.object_id AND i.index_id = ic.index_id
INNER JOIN sys.columns c
    ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE OBJECTPROPERTY(i.object_id, 'IsIndexedView') = 1
ORDER BY view_name, index_name, ic.key_ordinal;

这些查询在你想搞清楚线上环境到底有哪些索引视图、哪些索引列的时候非常实用。你排查性能问题时，第一部分先整理"有哪些物化的对象"，第二步再确认"优化器有没有真的去用它"。

4.2 修改视图定义的正确姿势

索引视图一旦建了索引，你想修改视图的定义就麻烦一些。因为索引是依赖视图定义的，视图定义一变，索引的聚合逻辑就可能对不上。

SQL Server不允许你直接ALTER VIEW一个带索引的视图。你只能：

先删除视图上的所有索引。
再ALTER VIEW修改视图定义。
重新创建索引。

这中间会有一个"空窗期"：索引删了之后到索引重建之前，查询会回到普通视图方式，性能可能骤降。如果你的基表数据量很大，重建索引的时间可能需要几分钟到几十分钟，这段时间系统压力会明显上升。所以我的建议是，所有修改索引视图结构的操作都放在业务低峰期，通知业务方，预留足够时间窗口。

删除索引和普通表一样：

sql复制DROP INDEX UIX_CustomerOrderStats ON dbo.v_CustomerOrderStats;

删除所有索引后，视图就变回一个普通视图，数据物化消失，但视图本身还在。

如果把整个视图删掉，则必须连带删除所有依赖索引：

sql复制DROP VIEW dbo.v_CustomerOrderStats;

这里再补充一个细节：如果你要重建索引，WITH (DROP_EXISTING = ON)可以一步到位，省得先删后建中间的碎片化：

sql复制CREATE UNIQUE CLUSTERED INDEX UIX_CustomerOrderStats
ON dbo.v_CustomerOrderStats (CustomerID)
WITH (DROP_EXISTING = ON);

4.3 索引视图的统计信息和碎片管理

索引视图和普通表一样，也有统计信息和碎片。长时间频繁更新后，聚集索引的碎片率上升，统计信息的采样也可能过期，这会导致查询计划走偏。

定期维护索引视图索引，可以参考普通索引的维护逻辑：

sql复制-- 查看碎片率
SELECT 
    OBJECT_NAME(ps.object_id) AS index_view_name,
    i.name AS index_name,
    ps.index_type_desc,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(
    DB_ID('IndexViewDemo'), 
    OBJECT_ID('dbo.v_CustomerOrderStats'),
    NULL, NULL, 'LIMITED') ps
INNER JOIN sys.indexes i
    ON ps.object_id = i.object_id AND ps.index_id = i.index_id;

如果碎片率超过30%，重组或重建索引。大索引建议REORGANIZE，超过一定阈值建议REBUILD。

统计信息的更新也别忘了。索引视图上的统计信息主要靠自动更新，但如果你的数据变化是批量方式（比如晚上ETL一次性灌几百万行），自动更新的采样可能跟不上，建议在ETL之后手动更新关键索引视图的统计信息：

sql复制UPDATE STATISTICS dbo.v_CustomerOrderStats;

这些都是日常运维会碰上却很少有人提醒的细节。索引视图不像普通表那么"常见"，相关的索引维护脚本、碎片监控、统计信息更新经常被疏漏，等查询突然变慢才发现索引视图统计信息过期了。

5. 索引视图的代价与常见坑，DBA必须知道的避坑指南

5.1 最容易被忽视的更新开销

索引视图的物化不是免费的。每一笔插入、更新、删除操作，SQL Server在更新基表数据的同时，还要评估索引视图是否受影响，然后去更新对应的物化行。这意味着，原本一条INSERT只要写一个聚集索引，现在多了一个索引视图的维护链路。

更麻烦的是，SQL Server在很多情况下对基表的UPDATE/DELETE操作，在涉及索引视图时执行计划会退化为"先删除旧行、再插入新行"的拆分模式，这在有大量UPDATE事务时性能影响很明显，而且会产生额外的锁和日志记录。

所以有个很实用的经验法则：索引视图的收益和代价是"零和博弈"，你用查询性能换写性能。如果你的业务是读多写少、更新不频繁，比如报表查询、BI分析、数据仓库汇总层，收益远大于代价；如果你的业务是电商交易、订单流水这类高频写入场景，我强烈建议你先做压力测试，再把索引视图从架构方案里去掉。

5.2 优化器"不鸟"索引视图的常见原因

这个坑我见过太多次了。建好了索引视图，查询也匹配，但执行计划里就是不用。

原因一：会话设置不满足。ARITHABORT是典型，ADO.NET传统驱动默认是OFF，ODBC是ON，这导致同一个查询在SSMS和应用程序里表现完全不一样。解决办法是应用程序连接字符串或启动语句里强制设置：

sql复制SET ARITHABORT ON;

原因二：版本和版本之间的行为差异。SQL Server的企业版对索引视图的支持和优化器自动匹配更激进，而标准版和一些低版本上，查询优化器可能不会自动使用索引视图，非要你加WITH (NOEXPAND)提示才能强制走。

sql复制SELECT 
    CustomerID, TotalAmount, OrderCount
FROM dbo.v_CustomerOrderStats WITH (NOEXPAND)
WHERE CustomerID = 1001;

NOEXPAND的意思是告诉优化器：不要展开视图，直接按索引视图的物化数据访问。对于标准版或优化器评估偏保守的场景，这一招很有效。但要注意，NOEXPAND在SQL Server的某些版本上有语法限制，加了之后查询计划锁定在索引视图上，如果数据不是最新（索引视图同步有延迟），你可能查到旧数据。

原因三：视图的查询和你写的查询"语义不完全等价"。比如你的查询加了WHERE CustomerLevel = 'A'，但索引视图的WHERE条件是日期范围，优化器做视图匹配时会评估查询是否完全包含在视图范围内。如果你要查的数据超出了视图的过滤条件，它就不能用这个视图。还有一种情况：你查询用了CONVERT对列做类型转换，视图里没有这个转换，优化器无法把查询映射到视图的列上。

原因四：基数估计和代价模型判断。优化器不是傻子，如果基表统计信息显示数据量很小，普通扫描可能比读取索引视图更快，它自然会选择不用索引视图。所以有时候不是"不鸟"，而是"不值得鸟"。你去看看执行计划的实际行数和估计行数，如果直方图过期、行数严重偏差，优化器做了错误判断，解决方式是更新统计信息，而不是强行加NOEXPAND。

5.3 索引视图 VS 普通索引 VS 列存储索引

很多人把这三者搞混，这里干脆放在一起对比一下。

对比项	普通索引（表上）	索引视图	列存储索引
存储位置	基于堆或聚集索引的B树结构	视图物化结果集，独立存储	基于表的列式存储
用途	加速单表查询	加速预计算聚合、JOIN结果	加速大表分析型查询
维护代价	每DML都要维护	每DML都要维护，且额外计算视图聚合	批量加载高效，但单行更新代价高
使用条件	没有限制	要求满足一堆SET选项和视图定义约束	企业版，兼容级别高
常见问题	碎片、统计信息过期	优化器不匹配、更新锁冲突、写放大	行存和列存切换导致的性能抖动

实际使用中，如果你只需要加速某个具体表的筛选和排序，普通索引就够了。如果你经常查询复杂的JOIN+GROUP BY结果，而且结果集可以预先按唯一键定义，索引视图很合适。如果你面对的是几亿行的大表做分析型查询，列存储索引通常比索引视图更高效，因为列存储压缩率高、扫描带宽大，但列存储对单行更新支持差。选型时先问自己：数据有多频繁更新？查询模式是否固定？结果集是否可明确定义唯一键？

5.4 我的索引视图排查清单

最后分享一份我自己的排查清单。每次线上有人反馈"索引视图没用上"或者"建了索引视图反而更慢"，我会按这个顺序从头到尾捋一遍：

确认索引视图真的存在索引。sys.indexes查一下，没有聚集索引的就是普通视图。
确认会话SET选项。重点看ARITHABORT、ANSI_NULLS、QUOTED_IDENTIFIER、CONCAT_NULL_YIELDS_NULL，这几个不对基本白搭。
确认视图定义满足所有约束。COUNT_BIG(*)写没写？SCHEMABINDING加了没？查询里有没有UNION、子查询？
查看执行计划。图形化计划里有没有索引视图节点？如果没有，右键查看属性里的"视图展开"，看看优化器是怎么处理你的查询的。
检查统计信息新鲜度。DBCC SHOW_STATISTICS('dbo.v_CustomerOrderStats', 'UIX_CustomerOrderStats')看采样时间和行数，偏离太夸张就先更新。
尝试WITH (NOEXPAND)强制使用。如果强制之后性能明显优于普通查询，但自动匹配不走，说明优化器代价模型判断有问题，优先处理统计信息而不是一直靠提示。
监控写路径的性能。如果在大量INSERT/UPDATE期间，sys.dm_db_index_usage_stats里索引视图的用户更新数暴涨，说明你就是那个"越建越慢"的受害用户。

这套清单帮我定位过不少问题，很多"索引视图失效"的案子最后都落在会话设置和统计信息过期这两项上。

另外再说一个细节，sys.dm_db_index_usage_stats这个动态管理视图对索引视图和普通表索引都会记录usage信息，你可以通过它看到索引视图到底被引用过多少次：

sql复制SELECT 
    OBJECT_NAME(index_id > 0 AND object_id = OBJECT_ID('dbo.v_CustomerOrderStats') 
        THEN object_id END) AS obj,
    *
FROM sys.dm_db_index_usage_stats
WHERE object_id = OBJECT_ID('dbo.v_CustomerOrderStats');

这个查询可以帮你判断线上的索引视图到底是不是"建了没人用"冷板凳角色。

6. 写在最后：一次真实的生产事故复盘

我在实际项目里遇到过一件挺尴尬的事。有张核心报表按订单明细做月度汇总，团队为了提高查询性能建了索引视图，上线后第一天确实快了不少，快得让人上头。结果没两天，ETL的批量导入任务开始出现锁等待超时，DBA排查了很久，最后发现就是索引视图在每一批UPDATE提交之后，要同步更新那份物化聚合结果，产生大量锁竞争和日志写入，硬生生把原本毫秒级的批量导入拖成了秒级甚至分钟级。

后来我们怎么解决的？没有整体删掉索引视图，而是把策略改成分层处理：ETL先导入到一张临时表，再通过一次性MERGE将差异数据写入主表，同时禁用索引视图上的非必要非聚集索引，只保留那个唯一的聚集索引。MERGE一个批次只触发一次物化更新，锁竞争立刻缓解。这个方案在实践中踩了几次坑才跑通，比如MERGE语句的并发量不能太高，否则仍会碰到锁升级；又比如临时表的数据量如果达到一定阈值，MERGE的代价反而不如直接分批次UPDATE。

所以无论工具多强大，脱离业务场景谈优化就是耍流氓。索引视图这个功能，理解了它的工作原理和代价模型，用对场景它就是性能利器，用错场景它就是定时炸弹。我个人的习惯是，在考虑索引视图之前，先跑一次普通聚合查询和可能的列存储索引方案，做一轮成本对比，只有数据量、查询频率和更新频率都满足条件时才考虑用索引视图。把复杂留给后台，把正确留给业务。