业务优化案例一则

本文讲述调整 sql 逻辑达到优化目的案例

一前言

前面一篇文章说过在有赞的数据库运维体系里面，每个实例会部署相应的sql-killer工具，实时处理耗时比较长的查询。 业务方报执行某个功能时，系统报错 Query execution was interrupted ，显然sql被kill了。和开发沟通业务逻辑如下:

系统会获取满足参加特定活动且满足一定次数的商家,然后做其他相关操作。

二 分析

前文< 业务优化案例一则 >分析过sql变慢的原因大概有如下几种: 

1. sql 语句本身索引不合理，导致执行缓慢。

2. 使用合理的索引但是获取的数据量非常多，依然会慢查。

3. 网络丢包重传导致sql变慢,被kill。

4. 并发比较高的场景，请求排队处理，等待时间长。

进过排查排除3,4两个因素。我们查看sql

 SELECT count(*) = 7 has_match,t_id
  FROM xxx
  where status = 1
  and task_id in (301, 302, 305, 306, 307, 308, 309) and t_id > 2019
  group by t_id order by t_id desc limit 10000

该sql的功能是获取t_id大于某些值的所有记录并且做聚合，然后把参加过task_id且次数等于7的t_id取出来。拿到sql，然后去查看表结构只有task_id 一个索引。和明显慢查的一个原因是没有合理的索引。

三 优化 

首先根据sql的where条件我们可以针对该sql加上索引 

KEY `idx_taskid_st_tid` (`task_id`,`status`,`t_id`) 

其次 原sql是将所有的记录取出来，通过count(*) = 7 表达式判断是否为1，再拿到程序中处理has_match为1的t_id。针对此我们可以利用 having 函数计算满足条件的记录。优化后的结果如下:

SELECT t_id,count(*) as num
FROM xxx
where status = 1
AND task_id IN (301,302,305,306,307,308,309)
group by t_id  having num=7;

优化之前 

优化之后

四 总结

这个案例相对比较简单，拓展一下数据库优化的核心思想:  三减少，一增加