SQL Server性能优化案例分享（1）——CPU持续过高——CPU高使用率的常见原因及处理方向

本系列属于 SQL Server性能优化案例分享 专题

    部分内容借用《SQL Server 2012实施与管理实战指南》P592，如果SQL Server错误日志里面并没有17883/17884这类错误，但是SQL Server CPU很高，那一般就是工作负载太高导致的。意味着SQL Server并没有什么大问题，但是很辛苦地在完成用户发过来的请求。

    由于CPU较于内存、阻塞、磁盘等资源瓶颈而言相对较后，所以SQL Server的CPU使用率一般不会太高，如果60~70%就已经算是很高了。那么一般集中使用CPU的资源有那些？

1. 编译和重编译
2. 排序和聚合计算：order by 、distinct、AVG、SUM、MAX、MIN等。
3. 表关联，特别是选择了错误的JOIN算法。

    一般要在SQL Server配置上能做手脚的根据个人经验，主要是Max Degree of Parallelism和Cost Threshold of Parallelism。

处理CPU高的常规思路

1. 确定CPU使用率到底多少，其中多少是SQL Server导致的

    可以使用计数器，也可以使用代码做一个粗略的计算获取实例性能概要信息。计数器可以考虑：

• Processor: % Processor Time
• Processor: % Privileged Time (Kernel Mode)
• Processor: % User Time (User Mode)
• System: Processor queue length
• Context switches/sec
• Process: % Processor time
• Process: % Privileged time
• Process: % User time

2. 检查SQL Server错误日志是否有17883/17884之类的错误

       健康的SQL Server其错误日志应该比较干净。

3. 找出CPU 100%时，SQL Server 正在运行什么

    这个其实有点难度，除非周期性发生。虽然有一系列的DMV可以使用，但是由于驻留内存的特性，可能会在动手之前已经重启服务器导致信息丢失。而开启sql trace又容易加大负担。这个时候，可以考虑使用扩展事件配合周期性运行查询DMV的语句并存储在实体表中的方式。后者使用类似Zabbix这类第三方监控软件