联合索引设置不当导致慢sql-j9九游会登录

场景描述

业务侧rds for mysql实例上以往执行耗时8秒的查询，在11:00后耗时超过30秒。

原因分析

1. 查看查询变慢对应的时间段中，实例cpu监控指标并无飙升情况且使用率一直都较低，因此排除了cpu冲高导致查询变慢的可能。
   图1 cpu使用率
   
2. 分析对应时间段该实例的慢日志，该sql执行快时其扫描行数为百万级，当sql执行慢时其扫描行数为千万级，与业务确认该表短期内并无大量数据插入，因此推断执行慢是因为未走索引或选错索引。且通过explain查看该sql的执行计划确实是全表扫描。
   图2 慢日志
   
3. 在实例上对该表执行show index from检查三个字段的索引区分度（或基数）。
   图3 查看索引区分度
   

   可知基数最小的字段“query_date”在联合索引的第一位，基数最大的字段“group_id”在联合索引最后一位，而且原sql包含对“query_date”字段的范围查询，导致当索引走到“query_date”就会停止匹配，后面两个字段已经无序，无法走索引。所以该sql本质上只能利用到对“query_date”这一列的索引，而且还有可能因为基数太小，导致优化器成本估计时选择了全表扫描。

   业务重新创建了联合索引将“group_id”字段放在第一位，“query_date”字段放在最后一位后，查询耗时符合预期。

j9九游会登录的解决方案

1. 查询变慢首先确认是否由于cpu等资源达到性能瓶颈导致执行慢。
2. 库表结构设计不合理，索引缺失或索引设置不恰当会导致慢sql。
3. 表数据大批量插入删除等操作可能会导致统计信息未能及时更新，建议定期执行analyze table防止执行计划走错。