如何解决SQL Server中索引视图因统计信息陈旧造成的扫描问题？

索引视图执行计划出现Table Scan的根本原因是SQL Server优化器基于过时的底层表统计信息误判成本，放弃使用UNIQUE CLUSTERED INDEX；必须检查并更新Orders等物理表的统计信息（如DBCC SHOW_STATISTICS），而非视图自身统计，且更新后才可重建视图索引。

为什么索引视图执行计划里突然出现 Table Scan？

这不是索引视图本身失效，而是 SQL Server 查询优化器基于过时的统计信息误判了数据分布，放弃使用已有的 UNIQUE CLUSTERED INDEX，转而选择全表扫描。尤其当底层表（如 Orders、Customers）数据量增长快、或批量导入后未更新统计信息时，这个问题会高频出现。

如何快速验证统计信息是否陈旧？

别猜，直接查。对索引视图对应的底层表运行：

DBCC SHOW_STATISTICS('dbo.Orders', 'IX_Customer_OrderDate');

重点看 LastUpdated 时间戳和 Rows 与 Rows Sampled 是否严重偏离当前真实行数。如果 LastUpdated 是几天前，且 Rows 比 COUNT(*) 少 20% 以上，基本可判定为陈旧。

注意：索引视图自身的统计信息（如 vw_SalesSummary 上的统计）不会自动更新，它完全依赖底层表的统计。所以只查视图名没用，必须查物理表。

更新统计信息的实操要点

对索引视图涉及的所有底层表，执行以下操作：

• 优先用 UPDATE STATISTICS dbo.Orders WITH FULLSCAN; —— 数据量 ≤ 100 万行时最稳妥，避免抽样误差
• 若表超 500 万行，改用 UPDATE STATISTICS dbo.Orders WITH SAMPLE 30 PERCENT;，平衡耗时与准确性
• 禁用自动更新？不行。确保 auto_update_statistics 和 auto_update_statistics_async 均为 ON（可通过 sys.databases 查）
• 切勿只更新单个索引的统计（如 WITH INDEX），必须更新表级统计，否则视图优化器仍看不到整体分布

重建索引视图前必须确认的两件事

即使你重建了视图上的 UNIQUE CLUSTERED INDEX，若底层统计未更新，下一次查询仍可能走扫描。所以：

• 先跑 UPDATE STATISTICS，再执行 ALTER INDEX IX_vw_SalesSummary ON vw_SalesSummary REBUILD;
• 检查执行计划中是否还有 Index Seek 或 Index Scan —— 如果仍是 Table Scan，说明底层表统计没生效，不是视图问题

真正容易被忽略的是：索引视图的性能不取决于它自己有没有索引，而取决于优化器信不信底层表的统计数字。信错了，再好的索引也白搭。