其他
业务优化案例一则
本文讲述调整sql逻辑达到优化目的案例
一前言
前面一篇文章说过在有赞的数据库运维体系里面，每个实例会部署相应的sql-killer工具，实时处理耗时比较长的查询。 业务方报执行某个功能时，系统报错Query execution was interrupted，显然sql被kill了。和开发沟通业务逻辑如下:
系统会获取满足参加特定活动且满足一定次数的商家,然后做其他相关操作。二 分析
前文<业务优化案例一则>分析过sql变慢的原因大概有如下几种:
sql 语句本身索引不合理，导致执行缓慢。
使用合理的索引但是获取的数据量非常多，依然会慢查。
网络丢包重传导致sql变慢,被kill。
并发比较高的场景，请求排队处理，等待时间长。
进过排查排除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;优化之前
优化之后
四 总结
这个案例相对比较简单，拓展一下数据库优化的核心思想: 三减少，一增加
——The End——
推荐阅读