这些天看了一篇微软官方发布的MS SQL Server2008性能问题处理及优化的英文文档，里面知识点介绍地很详细，在现实工作中也很实用，遂产生了想把它翻译一下的念头。翻译的过程，既可以帮助自己复习一下这些技术，也可以向其他还不熟悉这一块的朋友介绍一些新的知识，何乐而不为呢。只是这篇文章有点长，我会分成几篇随笔去介绍，所以，不光是对我耐性的考验，也是对你的考验哦！
--------------------------------------------
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密集使用的操作，也会提到对应的检测及解决方法。
