实战记录：一次真实的线上SQL语句优化

本文章首发于头条号
架构之美



背景：最近重构公司一小模块的RPC服务，由于旧的服务框架监控对于边缘业务统计并不完善，切换到新服务之后，从慢SQL监控中发现了不少慢SQL语句，虽然并不是什么特别重要的业务，但是既然这东西到咱手上，就权当练练手吧。

总请求量

先看一下总请求量，做到心里有数。从这一小块服务的每日请求量统计来看，日均请求510万左右，不是很多，可以放心搞 :-)

慢SQL

到底执行耗时多久才算慢语句，这个得根据服务器的实际情况来定，这里统计的是超过100ms。我大致分了一下，主要有两类语句，查询列表跟查询总数。下面分别说一下：

list类型



通过统计我们得出第三类语句typeid全部为3

count类型



总的来看，我们要优化的语句一共3条，那个1.1%的先忽略不计。

表结构

记录总数 - 110990，数据量很小

数据分布

语句分析

1.SELECT id FROM article_type WHERE forum_id=8124 ORDER BY create_time DESC LIMIT 10；

该语句用于查询某个板块下最新的10个类型，explain看一下，语句用到create_time单列索引，extra一列显示为Using where，扫描行数6万多，慢的原因很明显，该版块的数据比较老，按时间轴扫描的话效率低下，几乎扫描了大半张表的数据。最优的办法是加个forum_id和create_time的联合索引，这里我们使用index_tfd索引就可以了，也就是语句中加一个typeid IN (1,2,3)的条件。

2.SELECT id FROM article_type WHERE typeid=3 AND FIND_IN_SET('810',`tags`) ORDER BY create_time DESC LIMIT 20;

该语句类型为3的并且带有某中标签的id，我也很无奈，tags存储的是以逗号分割的标签id。还是分析一下语句，发现走的依然是create_time这个索引，数据占比不到6%，按时间轴查找数据效率不高，同时还发现tags字段只有typeid为3的记录才有值，根据当前的数据量，添加typeid和create_time联合索引便可。但是这也是不是最优的，为什么？

3.SELECT count(1) as num FROM article_type WHERE uid=7872232 AND typeid IN (1,2) LIMIT 1

这个无须多讲，添加uid和typeid索引即可化解问题。