1. 问题原因
1.1 应用负载（QPS）高
1.2. 查询执行成本（查询访问表数据行数 avg_lgc_io）高
2. 解决方法
2.1 应用负载（QPS）高
2.2 查询语句执行成本（查询访问表数据行数）高
3. 避免出现 CPU 使用率达到 100% 影响业务的一般原则

---

1. 问题原因：

应用提交的查询（包括数据修改操作）执行所需大量的逻辑读（逻辑IO，执行查询所需访问的表的数据行数），系统需要消耗大量的 CPU 资源用于维护从存储系统读取到内存中的数据一致性。

注：本文不排除由于MySQL 其他原因（比如大量行锁冲突、行锁等待）或后台任务原因导致的实例 CPU 使用率高，但这种情况出现的概率是非常低的，在此不做讨论。

通过一个简化的模型来说明 系统资源、语句执行成本 以及 QPS（Query Per Second 每秒执行的查询数）之间的关系：

条件：应用模型恒定（应用没有修改），

avg_lgc_io：每条查询执行需要的平均逻辑 IO

total_lgc_io：实例 CPU 资源单位时间能够处理的 逻辑IO 总量

公式：

total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行平均成本 x 单位时间执行的查询数量

下面列出 2 种典型 CPU 使用 100% 的场景：

1.1 应用负载（QPS）高

特征：实例的 QPS（每秒执行的查询次数）高，查询比较简单、执行效率高、优化余地小。

表现：没有出现慢查询（或者慢查询不是问题主要原因），QPS 和 CPU 使用率曲线变化吻合。

常见于应用优化过的在线事务交易系统（比如订单系统）、高读取率的热门Web网站应用、第三方压力工具测试中（比如 Sysbench）等。

1.2. 查询执行成本（查询访问表数据行数 avg_lgc_io）高

特征：实例的 QPS（每秒执行的查询次数）不高；查询执行效率低、执行需要扫描大量表中数据、优化余地大。

表现：存在慢查询，QPS 和 CPU 使用率曲线变化不吻合。

查询执行效率低，为了获得预期的结果集需要访问大量的数据（平均逻辑IO高），在 QPS 并不高的情况下（例如网站访问量不大），也导致实例的 CPU 使用率高。

注：由于查询执行效率低（查询访问表数据行数多）而导致实例 CPU 使用率高是RDS MySQL非常常见的问题。

2 解决方法

DMS 工具提供了几种不错的功能来辅助排查解决实例性能问题，主要有：

• 实例诊断报告

• SQL窗口提供的查询优化建议 和 查看执行计划

• 实例会话

其中实例诊断报告，是排查和解决 RDS MySQL 实例性能问题的最佳和最快捷工具。无论何种原因导致的性能问题，建议首先参考下实例诊断报告，尤其建议关注诊断报告的 “SQL优化”、”会话列表”、”慢SQL汇总”  部分。

2.1 应用负载（QPS）高

这种情况 SQL 查询优化的余地不大，建议考虑从应用架构、实例规格等方面来解决：

• 升级实例规格，增加 CPU 资源。

• 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。

• 使用京东云缓存产品，常用的查询结果尽量从缓存中获取，减轻数据库实例压力。

• 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用，考虑开启查询缓存（Query Cache）。

• 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。

• 尽量优化查询，减少查询的执行成本（逻辑IO，执行需要访问的表数据行数），提高应用可扩展性。

  注：能否从开启查询缓存（Query Cache）中获益需要经过测试。

2.2 查询语句执行成本（查询访问表数据行数）高

解决的原则：定位效率低的查询，优化查询的执行效率，降低查询执行的成本。

Step 1

如果当前 CPU 使用率比较高，可以通过 show processlist; 、show full processlist;

对于查询时间长、运行状态（State 列）是”Sending data”，”Copying to tmp table”、”Copying to tmp table on disk”、”Sorting result”、”Using filesort” 等都是可能有性能问题的查询（SQL）。

可以通过执行类似 kill 101031643; 命令来终止长时间执行的会话。

注1：在 QPS 高导致 CPU 使用率高的场景中，查询执行时间通常比较短，show processlist; 或实例会话中可能会不容易捕捉到当前执行的查询。

注2：也可以通过命令

explain select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on >= 2015-01-01 and a.detail = b.detail

来获取该查询 SQL 的执行计划，或者在 SQL 窗口的”执行计划”子标签页获取。

对于CPU使用率高的问题，建议关注诊断报告的 “SQL优化”、”会话列表”、”慢SQL汇总”  部分（再次强调下）。

注1：诊断报告同样适用于排查历史实例 CPU 使用率高的问题。

注2：对于 QPS 高和查询效率低的混合模式导致的 CPU 使用率高问题，建议从优化查询入手。

3 避免出现 CPU 使用率达到 100% 影响业务的一般原则

• 设置 CPU 使用率告警，实例 CPU 使用率保证一定的冗余度。

• 应用设计和开发过程中，要考虑查询的优化，遵守 MySQL 优化的一般优化原则，降低查询的逻辑 IO，提高应用可扩展性。

• 新功能、新模块上线前，要使用生产环境数据进行压力测试。

• 新功能、新模块上线前，建议使用生产环境数据进行回归测试。

• 建议经常关注和使用 DMS 中的诊断报告。