SQL存储过程本身不占CPU，真正消耗CPU的是低效执行计划、隐式转换、参数嗅探失准及频繁编译；需通过等待类型、编译率和执行计划特征定位根因，并优化索引、写法、配置与函数使用。
SQL存储过程本身不“占CPU”，真正吃掉CPU的是它执行时生成的低效执行计划、隐式类型转换、参数嗅探失准、或反复编译重编译——这些问题在高并发或大数据量下会集中爆发，让sqlservr.exe持续跑满单核甚至多核。
查清是不是真CPU瓶颈，别被表象骗了
先确认CPU高是根因还是结果：用sys.dm_os_wait_stats看等待类型，如果CXPACKET、SOS_SCHEDULER_YIELD、CMEMTHREAD排前三，大概率是CPU真忙；但如果PAGEIOLATCH_*或ASYNC_NETWORK_IO占比高，实际是I/O或网络拖慢了请求，CPU只是在空等。同时检查SQLServer:SQL Statistics\SQL Compilations/sec，若每秒编译数突增到50+，说明大量即席查询或参数化失败正在反复生成新计划，CPU被编译器榨干。
盯住执行计划里这3个高频罪魁
打开SET STATISTICS XML ON抓一个典型调用的实际执行计划，重点扫：
-
Index Scan或Table Scan节点：没走索引，全表扫几十万行，CPU全耗在逐行比对上 -
Compute Scalar套多层嵌套：比如WHERE UPPER(name) = 'ABC'，每次都要计算函数，无法利用索引且CPU密集 -
Hash Match或Sort操作出现在大结果集前：内存不足时溢出到tempdb，CPU+I/O双杀
特别注意Estimated Rows和Actual Rows严重不符（比如预估100行，实际50万行），这往往是参数嗅探导致计划失准的铁证。
绕开参数嗅探和游标陷阱的实操写法
别信“加WITH RECOMPILE就万事大吉”——那只是把问题从缓存转移到CPU。更稳的做法是：
- 对关键参数加
OPTION (RECOMPILE)，但只加在真正需要重编译的语句级，不是整个存储过程 - 用
OPTIMIZE FOR (@p = '常量')兜底，避免首次空值或极偏值污染计划缓存 - 彻底删除
DECLARE cur CURSOR——SQL Server游标默认是FAST_FORWARD，但仍是逐行取、逐行更新，换成UPDATE ... FROM集合操作，性能差10倍以上 - 批量操作必须显式控制批次，比如
TOP (2000) ORDER BY id推进，别用OFFSET 100000 ROWS，后者越往后越慢
所有涉及IN子查询或临时表的逻辑，确保关联字段有索引，且类型严格匹配（INT对INT，别用VARCHAR传数字）。
别忽略配置和部署层面的硬伤
很多CPU飙高根本不是SQL写的错，而是环境没配对：
- 确认
max degree of parallelism没设成0（不限制并行），尤其在OLTP系统里，MAXDOP 1反而是更稳的选择 - 检查
cost threshold for parallelism是否仍为默认5，小查询被强行并行反而增加调度开销 - 存储过程若含
SELECT INTO #tmp，确保tempdb数据文件数量=CPU核心数，且每个文件大小均等、自动增长关掉 - 上线前用
sp_updatestats更新统计信息，别依赖自动更新——大表自动更新采样率太低，计划极易走歪
最易被跳过的点：存储过程里调用的标量函数（fn_get_value()这类），每行都执行一次，哪怕函数只有1行代码，百万行就是百万次调用——改用内联表值函数或直接展开逻辑。
