一个表缺失索引起的CPU资源瓶颈案例

背景

近几日，公司的应用团队反应业务系统忽然变慢了，以前是一直比较正常。后与业务部门沟通了解详情，得知最近生意比较好，同时也在作大的促销活动，使得业务数据处理的量出现较大的增加，最终系统在处理时出现瓶颈。

分析和追踪问题的根源

首先：经过工具追踪服务器的性能，主要定位什么资源、在何时出现瓶颈。

这样的工具不少，能够网上搜搜工具和使用方法如PerMon和PAL等，最终获得结果是在业务高峰期（中午12点到23点前）以下图，CPU资源使用率一直很高，初步能够判断是CPU资源紧张。那真的“资源”不够吗？！不必定，进一步分析。

 

下一步，要更进一步实时监测到底什么东西在消耗CPU资源。

能够实时监控SQL Server资源的工具也不少，我这里使用的SQL Server Profiler，经过过滤和筛选相关Event后抓取想要的列，最主要是CPU这一列的值，以下：

 

上图，查看每一列CPU资源使用状况，看起来是否是很累，还好有另一个国外很好的工具ClearTrace，它能够很轻松地分析出trc文件中最占资源的如CPU/Reads/Writes等，这里重点分析CPU，以下图标出，第一二行就是致使CPU资源瓶颈的SQL语句

 

 

下一步，重点单独调试、分析上面列出的有问题语句。

我采用作法是将上面拷贝出来并填写对应条件参数的值，将整个语句拿到SSMS中单独调试，开启Actual Execution Plan和IO、Time统计，以下图显示单次执行logical read接近8.5w次，执行计划显示查找是经过索引扫描，这个表比较大，因此查询效率很低。而偏偏在这个案例中该语句执行频率极高，最终给资源特别是CPU形成很大损耗。

这里推荐你们另一个不错的执行计划分析工具sqlsentry plan Explorer。

　

接下来，试着在QA环境中，根据语句条件加上合适的非汇集索引。

看一下效果以下图，logical reads降到个位数，加上非汇集索引后，执行计划走的Index Seek，查询效率极大提高。

 

最后，实施到生产环境后，查看优化效果。

 

总结

不少时候，当咱们遇到系统性能问题，须要先收集数据后，再经过数据分析肯定问题根源。本案例在平常数据库运维中比较典型的，常规入手点就是检查PerfMon输出，已识别Memory、I/O 、CPU的瓶颈，资源瓶颈可能就是来自于某个或几个执行效率特别差的查询语句，通过适当的数据收集、分析处理基本能够锁定根源，并经过适当的方法如调整索引、调整语句写法等基本能够解决主要性能问题，特别是在系统上线不久这些问题尤其明显。另外就是随着时间推移，系统的业务压力增长，数据量增长也会带来相似性能问题。总的来讲，建议必定要先从应用层面、数据库中索引、存储过程代码等最基本的方面入手进行调优，最大程度榨取提高性能的空间，而后再考虑数据库配置、硬件等。另外特别提醒，解决一个瓶颈可能带来另外一个瓶颈，因此建议对调优的内容作一段时间的监控。