视图慢的根源是底层表统计信息过期，需通过执行计划定位偏差超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 强制重编译

统计信息只是起点。视图慢还常混着参数嗅探、临时表未建统计、分区表跨分区谓词失效等问题——更新完立刻看执行计划是否重构，而不是只盯耗时数字。