对视图执行 UPDATE STATISTICS 无效，因其非物理对象；该命令仅适用于表或索引视图，普通视图调用会报错Msg 156；SQL Server 对视图的基数估计完全依赖底层基表的统计信息质量。
视图本身不存储数据，也不直接拥有统计信息；SQL Server 对视图的基数估计完全依赖于其底层基表的统计信息质量。想靠“调视图”提速，本质是调基表的统计信息 + 索引 + 查询写法。
为什么对视图执行 UPDATE STATISTICS 没用？
视图不是物理对象，UPDATE STATISTICS 只能作用于表或索引视图（即带 UNIQUE CLUSTERED INDEX 的视图）。普通视图调用该命令会报错：Msg 156, Level 15, State 1, Line X: Incorrect syntax near the keyword 'VIEW'。真正要更新的是视图里所有 FROM 和 JOIN 涉及的基表统计信息。
- 先查清视图展开后实际访问了哪些表：用
SET SHOWPLAN_XML ON执行视图查询，看执行计划里的TableScan或IndexScan节点 - 对每个基表运行
UPDATE STATISTICS [schema].[table] WITH FULLSCAN（尤其当数据量小或分布极不均匀时） - 若表有频繁
INSERT/UPDATE/DELETE，改用自动更新 + 增量统计（SQL Server 2016+ 支持）：CREATE STATISTICS ... WITH INCREMENTAL = ON
视图中 JOIN 列缺失统计信息会导致严重低估
当视图包含 JOIN t1 ON t1.id = t2.ref_id，但 t2.ref_id 列没有单列统计信息（哪怕有复合索引），SQL Server 会退回到非常保守的基数估算（常为 1 行或总行数的 1%），进而错误选择 Nested Loop 而非 Hash Join，拖慢整个执行流。
- 检查缺失：运行
DBCC SHOW_STATISTICS('t2', 'ref_id')，若报错Cannot find statistics就确认缺失 - 补统计：直接建单列统计即可，无需索引：
CREATE STATISTICS [stat_t2_ref_id] ON t2(ref_id) - 注意顺序：如果已有复合统计如
ON t2(status, ref_id)，但查询只过滤ref_id，该统计的直方图仍只基于status列——此时仍需单独为ref_id建统计
参数化视图查询触发 PSP 时，基数估计行为会变复杂
如果你通过存储过程传参查询视图（如 SELECT * FROM v_sales_summary WHERE year = @y），且 @y 值分布高度倾斜（比如 90% 数据在 2023 年），SQL Server 2022 的参数敏感计划（PSP）会为不同年份生成多个查询变体，每个变体使用各自适配的基数估计逻辑。这本是优势，但容易被忽略两点：
- PSP 默认最多只对 3 个谓词做分桶；如果视图里有
WHERE year = @y AND region = @r AND status = @s，它可能只挑前两个，第三个被忽略，导致该分支估计失真 - 视图定义若含
SELECT *或未显式指定列，优化器可能无法下推外部谓词到基表，使 PSP 失效——务必在视图定义中只写明确需要的列 - 验证是否启用 PSP：在执行计划 XML 中搜索
ParameterSensitivePlan="true"，并检查QueryVariant节点数量
最易被忽略的一点：视图性能问题 90% 出现在第一次执行时——因为统计信息陈旧 + 参数嗅探 + 缺少增量统计，导致初始编译选错计划；后续执行即使数据已更新，只要计划没失效，就继续错下去。别只盯着“视图怎么写”，先盯住 sys.dm_db_stats_properties 里 modification_counter 是否远超阈值。
