CPU使用率高的原因和解决方法
发布时间：2025-06-08 17:37
问题原因
哎哟，你们知道不？有时候咱们在使用网站或者APP的时候，突然就卡住了，这到底是咋回事呢？其实就是系统在执行查询操作或者数据修改操作的时候，得进行一大堆的逻辑读操作。这就像咱们去图书馆找书，得翻来覆去地找，挺费劲的。而这些操作又需要访问表中的数据行数，所以系统就得消耗好多CPU资源，来保证从存储系统读取到内存中的数据一致性。
解决方案
那怎么办呢？对于这种因为应用负载高导致的CPU使用率高的情况，咱们得从应用架构、实例规格等方面来想办法解决。比如说，可以升级实例规格，增加CPU资源；或者增加只读实例，把一些对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，这样就能分担主实例的压力。还有，使用云数据库Memcache或者云数据库Redis，尽量从缓存中获取常用的查询结果，这样也能减轻RDS实例的压力。定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量，也是挺有用的。就是要尽量优化查询，减少查询的执行成本，提高应用的可扩展性。
- 升级实例规格，增加CPU资源。
- 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力，详情请参见读写分离。
- 使用云数据库Memcache或者云数据库Redis，尽量从缓存中获取常用的查询结果，减轻RDS实例的压力。
- 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。尽量优化查询，减少查询的执行成本，提高应用可扩展性。
更多信息
下面，咱们通过一个简化的模型来了解一下系统资源、语句执行成本以及QPS（每秒执行的查询数）之间的关系。条件是应用模型恒定，即应用没有修改。然后，avg_lgc_io表示执行每条查询需要的平均逻辑IO，total_lgc_io表示实例的CPU资源在单位时间内能够处理的逻辑IO总量。关系公式是：total_lgc_io=avg_lgc_io×QPS，即单位时间CPU资源=查询执行的平均成本×单位时间执行的查询数量。
- 条件：应用模型恒定，即应用没有修改。
- avg_lgc_io：执行每条查询需要的平均逻辑IO。
- total_lgc_io：实例的CPU资源在单位时间内能够处理的逻辑IO总量。
- 关系公式：total_lgc_io=avg_lgc_io×QPS即单位时间CPU资源=查询执行的平均成本×单位时间执行的查询数量。
- 设置CPU使用率告警，实例CPU使用率保证一定的冗余度。
- 应用设计和开发过程中，要考虑查询的优化，遵守MySQL优化的一般优化原则，降低查询的逻辑IO，提高应用可扩展性。
- 新功能、新模块上线前，要使用生产环境数据进行压力测试。
- 新功能、新模块上线前，建议使用生产环境数据进行回归测试。