视图慢的根源是底层表统计信息过期，需通过执行计划定位偏差超10倍的表，检查DBCC SHOW_STATISTICS中的Modification Counter与Rows Sampled比例，并用STATS_DATE确认更新时间；更新后须手动清除计划缓存。
视图本身不存统计信息，它的执行计划完全依赖底层表和索引的统计信息。所以“视图慢”，大概率是它引用的某个基础表的 STATS_DATE 已严重滞后，导致优化器选错连接方式或访问路径。
怎么确认是视图里哪张表的统计信息拖了后腿？
别猜，直接查。重点不是看视图定义，而是抓它实际执行时用到的物理对象：
- 先用
SET STATISTICS XML ON执行一次慢视图查询，从执行计划里找到所有Table Cardinality和EstimateRows/ActualRows差距超 10 倍的算子（比如 Nested Loops 下方的 Table Scan） - 对这些表运行：
DBCC SHOW_STATISTICS('table_name', 'stats_name')，重点关注输出里的Modification Counter和Rows Sampled—— 若前者 ≥ 后者 × 0.2，就基本坐实过期 - 补充验证：查
sys.stats视图，用STATS_DATE(object_id, stats_id)看最近更新时间，超过 7 天未更新的大表要优先怀疑
UPDATE STATISTICS 对视图生效吗？
有效，但必须作用在底层表上，且不能只靠 sp_updatestats：
-
sp_updatestats只更新“有数据变更”的表，且默认采样率对大表（尤其 > 5000 万行）严重不足，容易漏判 - 对视图核心表，建议显式执行：
UPDATE STATISTICS table_name WITH FULLSCAN, COLUMNS（小表）或WITH SAMPLE 30 PERCENT（大表） - 如果视图含计算列或表达式，确保对应列的统计信息也更新——加
COLUMNS参数才能覆盖非索引列
为什么更新完统计信息，视图还是走老计划？
因为执行计划缓存没刷新，SQL Server 不会自动为视图重编译。常见卡点：
- 检查该视图对应查询的
plan_handle是否还在缓存里：SELECT plan_handle, usecounts FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st WHERE st.text LIKE '%your_view_name%' - 手动清除：
DBCC FREEPROCCACHE(@plan_handle)（推荐），或更精准地用sys.dm_exec_query_stats找出plan_generation_num没变的语句再清 - 注意：如果视图被嵌套在存储过程中，得清整个过程的缓存，或干脆在过程里加
WITH RECOMPILE强制重编译
统计信息只是起点。视图慢还常混着参数嗅探、临时表未建统计、分区表跨分区谓词失效等问题——更新完立刻看执行计划是否重构，而不是只盯耗时数字。
