CPU瓶颈（一）

      CPU瓶颈问题可由硬件资源相对于当前负荷不足而导致。 然而，过度的CPU使用率通常可以通过对查询进行优化（特别是突然出现的增长但并没有额外的负载或者其它的查询发生在服务器上）、定位所有可能的应用程序设计因素、优化系统配置去降低。在你匆匆去购买更快、更多的处理器之前，识别出最大的CPU带宽消耗者，并且去查看下是否可以优化这些查询语句或者校正那些设计/配置因素。

      通常而言，为了确定服务器是否处于CPU限制，性能监视器是的最简单工具之一。你应该去查看Processor:%Processor Time计数器是否很高；如果每个处理器的平均处理时间持续高于80%，我们通常就可以认为已经遭遇了CPU瓶颈。

      在SQL Server内部，你也可以使用SQL Server自带的动态管理视图去检查CPU瓶颈。SOS_SCHEDULER_YIELD类型的请求等待或者大量的“可被执行”的任务预示着“可被执行”的线程正在等待着被安排执行并且这个处理器上可能存在着CPU瓶颈。如果你已经启用了数据收集器，Server Activity报表上的SQL Server Waits图表将会帮助您很方便地随时追踪CPU瓶颈。被消耗的CPU以及SOS_SCHEDULER_YIELD等待这两项被收缩在了报表上的CPU 等待这个类别里， 并且如果你看到了高CPU使用，你可以使用下钻功能去查看那条SQL语句消耗了最多的资源。

      下面的这个查询语句帮助你从较高的层级查看当前哪些缓存的批处理或者过程对CPU的占用最高。这个查询语句对所有语句的CPU消耗时间进行汇总，并且按照plan_handle（意思是说它们属于同一个批处理或者过程）进行分组。如果结果中有plan_handle对应的语句个数超过了一个的，你可能就不得不更深入地查找是哪个语句造成了最大的CPU占用。

   select top 50
         SUM(qs.total_worker_time) as total_cpu_time,
         SUM(qs.execution_count) as total_execution_count,
         COUNT(*) as number_of_statements,
         qs.plan_handle
   from sys.dm_exec_query_stats qs
   group by qs.plan_handle
   order by SUM(qs.total_worker_time) desc

      

    在本章接下来的内容里，我们会讨论在SQL Server中通常会遇到的一些CPU密集使用的操作，也会提到对应的检测及解决方法。