如果在没有额外复杂条件下突然出现CPU瓶颈，有可能是由于没有优化查询，错误的数据库配置，或者是数据库设计上的缘由和硬件资源不足惹起。在决定采用添加CPU数量或者使用更快速的CPU之前，应该先检查耗费CPU资源最多的操作能否能够被优化。

　　如果发现功用计数器Processor: % Processor Time的值很高，每一个CPU的% Processor Time都超过80%时，可视为出现CPU瓶颈。也可以通过视图sys.dm_os_schedulers监视SQL Server的进程调度（schedulers）来确认可执行的任务能否为非零值。非零值表示任务被迫等待时间片来运转，如果这个数值非常高，说明存在CPU瓶颈。

　　下面的查询将给出一个较高层的视图来说明当前被缓存的耗费CPU资源最多的批处理或者过程。查询通过相反查询句柄的所有语句合计CPU的耗费情况。

　　过多的compilation和recompilation

　　在批处理或者近程过程调用（RPC）提交到服务器执行之前，系统会检查查询计划的无效性和正确性。如果在检查过程中出现了失败的情况，这些批处理可能会被再次编译来产生新的查询计划。这样的编译被称为重编译（recompilations）。这些重编译普通必须确定正确性且通常在服务器认定在潜在数据发生变化后存在可能被优厚的查询计划时执行。编译的特性是CPU敏感的操作，因此过分的重编译可以导致CPU功用问题。