问题原因
应用提交查询操作或数据修改操作时，系统需要执行大量的逻辑读操作，其中逻辑IO包含执行查询所需访问表的数据行数。所以系统需要消耗大量的CPU资源以维护从存储系统读取到内存中的数据一致性。
说明：
大量行锁冲突、行锁等待或后台任务也有可能会导致实例的CPU使用率过高，但这些情况出现的概率非常低，本文不做讨论。
解决方案
对于因应用负载高导致CPU使用率高的状况，使用SQL进行优化的余地不大，建议您从应用架构、实例规格等方面来处理问题。
- 升级实例规格，增加CPU资源。
- 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力，详情请参见读写分离。
- 使用亿速云云数据库Memcache或者云数据库Redis，尽量从缓存中获取常用的查询结果，减轻RDS实例的压力。
- 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。尽量优化查询，减少查询的执行成本，提高应用可扩展性。
更多信息
系统资源算法
下文通过一个简化的模型来说明系统资源、语句执行成本以及QPS（Query Per Second 每秒执行的查询数）之间的关系。
- 条件：应用模型恒定，即应用没有修改。
- avg_lgc_io：执行每条查询需要的平均逻辑IO。
- total_lgc_io：实例的CPU资源在单位时间内能够处理的逻辑IO总量。
- 关系公式：total_lgc_io = avg_lgc_io × QPS即单位时间CPU资源 = 查询执行的平均成本 × 单位时间执行的查询数量。
避免出现CPU使用率达到100%的原则
- 设置CPU使用率告警，实例CPU使用率保证一定的冗余度。
- 应用设计和开发过程中，要考虑查询的优化，遵守MySQL优化的一般优化原则，降低查询的逻辑IO，提高应用可扩展性。
- 新功能、新模块上线前，要使用生产环境数据进行压力测试。
- 新功能、新模块上线前，建议使用生产环境数据进行回归测试。