SQL资源占用过高需从CPU和内存分层定位：先判别实例级或SQL级问题，再分析执行计划、数据量、锁等待及配置；CPU高查运行中高消耗会话与低效算子，内存高查缓冲池热点与内存授予偏差，同时排查锁阻塞、重编译和内存配置等隐藏因素。
SQL资源占用过高，核心要从CPU和内存两个维度定位瓶颈源头，而不是盲目优化语句或加索引。关键在于分层排查：先确认是数据库实例级压力，还是具体SQL导致；再区分是执行计划低效、数据量暴增、锁等待，还是配置不合理。
CPU高：重点查并发执行计划和函数开销
CPU持续高位，大概率是大量SQL在做复杂计算或重复解析。优先查正在运行的高CPU消耗会话：
- 用sys.dm_exec_requests + sys.dm_exec_sql_text 找到cpu_time高、status = 'running'的语句
- 特别关注含COUNT(*)、GROUP BY多字段、子查询嵌套深、标量函数（如UDF）、XML/JSON解析的SQL——这些极易吃满单核
- 检查执行计划中是否有Table Scan、Key Lookup、Nested Loops过度膨胀，尤其是预估行数 vs 实际行数偏差10倍以上时，统计信息很可能过期
内存高：盯紧缓冲池使用与查询内存授予
内存压力不等于“内存不够”，更常见的是内存被低效占用。分两块看：
- 缓冲池（Buffer Pool）：查sys.dm_os_buffer_descriptors，看是否大量数据页集中在少数大表——可能是频繁全表扫描或缺少覆盖索引，导致热数据无法驻留
- 查询内存授予（Grant）：用sys.dm_exec_query_memory_grants找requested_memory_kb异常高但granted_memory_kb远低于请求值的语句，说明内存不足触发等待，此时要调低min memory per query或限制并行度
别忽略隐藏元凶：锁、编译、配置
很多高资源占用其实和SQL本身无关：
- 长时间阻塞：一个未提交事务锁住大表，其他查询排队等锁，表现为大量会话status = 'suspended'、wait_type = 'LCK_M_XX'——先杀阻塞源头，再优化事务粒度
- 过度重编译：参数化失效或临时表频繁重建，导致CPU花在编译而非执行上。查sys.dm_exec_query_stats中plan_generation_num > 10的语句
- max server memory设得过大，挤占系统缓存或导致OS内存回收压力；设得太小又引发缓冲池频繁淘汰——建议保留2–4GB给OS，其余分配给SQL Server
快速验证与收敛路径
不要一上来就改代码。按顺序做三件事：
- 用sp_WhoIsActive @get_task_info=2, @get_outer_command=1抓实时快照，5秒执行一次，连抓1分钟，导出后按CPU, reads, tempdb_allocations排序
- 对Top 3高消耗SQL，强制清除其执行计划（DBCC FREEPROCCACHE (plan_handle)），观察资源是否回落——若回落，说明是执行计划老化或参数嗅探问题
- 开启Query Store并设置自动清理策略，长期跟踪性能退化趋势，比临时抓包更可靠
