系统稳定性测试过程中cpu使用率呈缓慢上升趋势

还是许久之前，开发让我帮忙看下他们做性能压测时候的awr报告，说是在做稳定性测试时候发现，随着时间的推移，cpu使用率会越来越高。

我当时取了两个小时的awr，通看了一下，觉得数据库各方面运行的挺好，而且sql语句也没有超过10ms的，应该是比较理想的系统。后来又取了连续10个小时的awr，分析出来结果也差不多。

于是怀疑是不是虚拟机有问题，因为我们测试环境的机器都是虚拟机，怀疑是不是虚拟机或者操作系统有问题。排查加鼓弄了半天，无所得。

让开发人员继续开启稳定性压测，我一直观察cpu使用情况，从早上到晚上下班，cpu使用率确实在缓慢提升，然后发现oracle单个进程占用的cpu资源也在缓慢的增长。意识到还是出现在oracle数据库上面了。

重新取了刚开始压测1个小时和最后一个小时的awr报告，对比了下top sql语句中的sql，发现同一条sql，随着时间的推移，逻辑读也在缓慢增长。豁然开朗了。sql语句存在缺陷，但很小，小到极其容易忽略。后分析sql，发现该sql所涉及的表存在比较严重的数据倾斜字段，而且该字段便是该sql语句的主要谓词条件，sql语句通过该字段上的索引来获取数据。

由于该字段存在较为严重的数据倾斜，加上稳定性测试过程中持续向该表中插入数据，导致倾斜度相对越来越大，该字段上的索引效率用来越低，继而导致sql语句随着时间的推移，越来越占用cpu。

之所以最初在分析时候觉得sql没啥问题，那是因为即使sql后来变慢了，也只是从原先微妙级别，变成了几毫秒，对于awr的sql执行时间粒度而言，依然都是属于小于10毫秒的，容易造成sql执行很棒的假象。

--------------------------------------------------------------------------------------------------

其实整个分析排查过程做的挺多的，当然，由于之前方向错了，走了很多冤枉路。也侧面说明了，方向上没出大问题，就没有大问题。

而我之所以想写下这个案例，是想告诫自己，不要为表象所迷惑，不要凭以往的经验草率的得出结论，凡事仍需谨慎细致。比如，判断一条sql语句到底有没有问题，好，列出sql的逻辑读和物理读，有没有变化，是不是持续变化，变化是否符合预期。