索引视图执行计划出现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，说明底层表统计没生效，不是视图问题
真正容易被忽略的是：索引视图的性能不取决于它自己有没有索引，而取决于优化器信不信底层表的统计数字。信错了，再好的索引也白搭。
