主要观点总结
本文描述了在进行数据库压测过程中遇到CPU利用率异常的问题，并详细记录了问题的排查过程。通过一系列的分析和监控，最终定位到是由于压测改造中的查询逻辑导致查询符合 effectiveStartTime <= now < effectiveEndTime 的最新一条任务时，随着压测的持续进行，查询到的符合条件的行数越来越多，导致CPU消耗逐渐增加。文章还介绍了相关的原理剖析和反思。
关键观点总结
关键观点1: 压测过程中CPU利用率异常的问题
描述了压测过程中遇到的问题，即随着压测流量的增加，CPU利用率异常升高。
关键观点2: 问题排查过程
详细记录了问题的排查过程，包括对比线上实际值与压测值、查看数据库性能指标等。
关键观点3: 问题定位
最终定位到是由于压测改造中的查询逻辑导致查询的行读异常，随着压测的持续进行，查询到的符合条件的行数越来越多，导致CPU消耗逐渐增加。
关键观点4: 原理剖析
对行读、逻辑读和物理读的概念进行了普及，并解释了它们之间的关系。
关键观点5: 反思与总结
对压测过程中的问题进行了反思，提出了在压测改造时，还需要关注改造方式与场景的匹配程度。同时强调了监控数据库性能指标的重要性。
文章预览
阿里妹导读 一次压测过程中，当数据库的qps和tps都正常时，如果cpu利用率异常的高，应该如何排查？希望通过这篇文章，给你一些启发。 业务背景 业务需要控制频道内兑换现金的数量，于是在产品设计上给兑换现金增加了库存限制。 在此基础上形成了秒杀场景，峰值时核心接口qps上涨了近600倍（几十到几万） ，因此需要进行压测来对系统和DB水位摸一下高。 压测准备 大致分为下面几个步骤： 1. 压测流量评估： 就是定一下每个接口大致压测多少qps，以及压测时到各个下游系统的流量估计； 2. 压测改造： 因为压测都是用的压测账户，在频道里没有历史痕迹，很多逻辑是走不到的，并且这些逻辑的不同，会直接影响到数据库和下游的流量，因此我们需要根据频道的现有数据进行链路的mock（包括上述的流量评估也得基于这些不同链路的比例去算）
………………………………
