一、问题背景

上个月将生产环境的某个库迁移到新的节点后，经常会在凌晨出现CPU偏高的告警。查看监控图表如图一所示。

图一、问题时间段的数据库资源使用指标曲线

根据告警日志排查，发现源头的数据库实例是一个从库，供业务系统大数据报表使用的，作为大数据ETL的数据源。

进一步，通过性能诊断工具查看，发生问题的时间段发现有密集的慢SQL。

图二、问题时间段的慢SQL

二、问题分析过程

2.1 资源负载和业务流量分析

在图一展示的各条SQL语句中，排名第一的Select语句最大执行时间16s。

首先查看与这条语句相关的资源负载和业务流量情况。如图三所示，在问题事件段，活跃会话数（AAS）最高一度达到了80，远超CPU核数，说明并发也很高，执行期间引起了cpu100%以及网络IO的明显增长（纵向对比同时间段的Utils和Bytes IN/OUT曲线的可以看到）。

图三、SQL关联分析

2.2 慢查询分析

图四、慢查询分析

捕获的样例SQL：

SELECT `layout_id`,... FROM channel_layout_api WHERE layout_id%100 >= 431494 AND layout_id%100 < 433160

• 如图四所示，选中问题SQL，点击“查询执行计划”，发现查询类型为ALL，即全表扫描，扫描行数接近35w。
• 查看样例SQL的查询条件，发现有使用%100取模运算。
• 取模后的条件比较也有问题，100取模后必定<486472，即该条件无过滤效果，结果集也是全表，没达到取模的效果。
• 查询数据库表结构与索引情况，结果如下，查询字段layout_id为主键索引。

channel_layout_api | CREATE TABLE `channel_layout_api` (
  `layout_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `create_time` bigint(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
  ......省略无关字段
  PRIMARY KEY (`layout_id`),
  .......省略无关索引
)