CXPACKET等待类型分析

背景

客户反馈今天8点钟开始进入业务高峰期后，数据库的CPU利用率非常高，基本达到了100%，前端应用也非常慢。怀疑是昨晚业务系统升级导致，请我们紧急协助分析。

现象

登录到SQL专家云，进入相关时间的活动会话的原始数据页面，看到很多会话的等待类型是CXPACKET，并且等待时间达到了几十秒。

查看具体的SQL语句，发现都很简单。

 

分析

首先简单介绍一下CXPACKET等待类型：当SQL Server进行某些复杂的运算（例如大表或索引的扫描）时，为了加快执行速度，采用多线程并行的方式进行，每个线程处理一部分数据，最后再进行结果合并，在等待一个或多个线程返回结果时就会产生CXPACKET等待类型，类似的等待类型还有CXCONSUMER。对于复杂的SQL语句，并行的方式可以大幅的降低执行时间，但是对于简单的、高并发的SQL语句，CXPACKET等待类型就会产生严重的性能问题。

如此简单的SQL语句还要使用并行，第一反应就是缺少合适的索引，通过SQL专家云的智能分析，在执行计划中发现行数为1900多万的表上有缺失索引，而且影响度非常高。

解决

表上创建好索引后，该语句的执行时间降低到几百毫秒，CXPACKET等待类型大幅减少，CPU利用率下降到10%以下。

经验

如果您的数据库有大量的CXPACKET等待类型，并且CPU利用率非常高，以下的经验基本可以帮助您解决问题

1. 配置最大并行度(Max Degree of Parallelism)参数，该参数是实例级别的(2016以后版本中可以对单独数据库设置) 。默认是0，对于一个SQL请求，可以使用全部的CPU核数进行并行调度，对于单个SQL请求来说是最好的，但是数据库是有并发的，就会导致其他的请求没有CPU资源，所以要在单个语句的执行时间和整体的并发之间取得一个平衡，对于OLTP系统，建议设置成4或者8，对于OLAP系统，可根据实际的并发请求数适当放大。
2. 创建合适的索引， 一个很简单的语句产生CXPACKET等待，绝大多数原因是没有合适的索引，创建合适索引后，语句会有几倍到几十倍的提升。
3. 找到高并发的SQL语句分析并行的原因并进行优化，避免并行。