复杂视图本身不消耗CPU，真正烧CPU的是其展开后生成的执行计划，尤其是嵌套多层、含非SARGable表达式且缺乏统计信息支撑的情况。
复杂视图本身不消耗CPU，真正烧CPU的是它展开后生成的执行计划——尤其是嵌套多层、含非SARGable表达式、又没统计信息支撑的那类。
查实时会话：别信“最近执行”的SQL，盯住cpu_time和wait_type
运行以下查询，重点看那些cpu_time持续增长但wait_type是CXPACKET或空（即没在等）的会话：
SELECT r.session_id, r.status, r.command, r.cpu_time, r.total_elapsed_time, r.wait_type, r.last_wait_type, t.text AS sql_text, qp.query_plan FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) qp WHERE r.status = 'running' AND r.cpu_time > 5000;
- 如果
sql_text里看到大量SELECT * FROM (SELECT * FROM (SELECT ...))结构，基本就是复杂视图被层层展开的结果 -
last_wait_type是CXPACKET且cpu_time远大于total_elapsed_time的，说明并行线程在自旋计算，不是I/O或锁卡住 - 别依赖
sys.dm_exec_query_stats——它只存缓存中的历史平均值，对突发毛刺无效
看执行计划：重点找“隐藏的全表扫描”和“重复计算节点”
拿到query_plan后，在SSMS中打开XML，用Ctrl+F搜这几个关键词：
-
RelOp LogicalOp="Compute Scalar"：视图里用了CONVERT、ISNULL或计算列，且没走索引，会导致每行都算一遍 -
RelOp LogicalOp="Nested Loops"+EstimateRows远大于实际数据量：统计信息陈旧，优化器误判，把小表当大表驱动 -
RelOp LogicalOp="Index Scan"或Table Scan出现在视图底层表上：说明WHERE条件里的字段没索引，或用了函数如YEAR(OrderDate)导致索引失效
调参止损：先控并行度，再禁用参数嗅探，别急着改视图
视图逻辑一时改不完，先压住CPU毛刺：
- 立即执行：
EXEC sp_configure 'max degree of parallelism', 2; RECONFIGURE;—— 多核CPU上默认0（不限制）极易引发并行自旋 - 对调用该视图的关键查询加提示：
OPTION (USE HINT('DISABLE_PARAMETER_SNIFFING'))，避免因首次参数导致计划退化 - 临时禁用自动更新统计信息：
ALTER DATABASE SCOPED CONFIGURATION SET AUTO_UPDATE_STATISTICS = OFF;，防止半夜刷新时触发计划重编译+全表扫描
验证是否真由视图引起：绕过视图直查底层表
拿视图里最外层的WHERE条件，直接写到最内层表上跑一次：
-- 假设视图定义是 SELECT a.*, b.Name FROM Orders a JOIN Customers b ON a.CustID = b.ID -- 那就直接跑： SELECT a.*, b.Name FROM Orders a WITH (NOLOCK) JOIN Customers b WITH (NOLOCK) ON a.CustID = b.ID WHERE a.OrderDate >= '2026-09-01' -- 这个条件原在视图外层 OPTION (RECOMPILE);
- 如果直查快、CPU低，说明问题出在视图展开逻辑或中间层统计信息不准
- 如果直查也慢，说明是底层表设计或索引缺失——这时候再看
sys.dm_db_missing_index_details - 注意：
WITH (NOLOCK)只是临时验证，别上线；OPTION (RECOMPILE)确保用最新统计信息
最常被忽略的一点：视图里一个GETDATE()或NEWID()函数，会让整个执行计划无法被缓存复用，每次调用都强制重编译——这种“伪动态”比真实业务逻辑更伤CPU。查sys.dm_exec_cached_plans时留意usecounts是否恒为1。
