业务优化案例一则

栏目: 数据库 · 发布时间: 5年前

内容简介:本文讲述调整sql逻辑达到优化目的案例前面一篇文章说过在有赞的数据库运维体系里面,每个实例会部署相应的sql-killer工具,实时处理耗时比较长的查询。 业务方报执行某个功能时,系统报错

业务优化案例一则

本文讲述调整 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;

优化之前 

业务优化案例一则

优化之后

业务优化案例一则

四 总结

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

业务优化案例一则

——The  End——

业务优化案例一则


以上所述就是小编给大家介绍的《业务优化案例一则》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

浅薄

浅薄

[美]尼古拉斯·卡尔 / 刘纯毅 / 中信出版社 / 2015-11 / 49.00 元

互联网时代的飞速发展带来了各行各业效率的提升和生活的便利,但卡尔指出,当我们每天在翻看手机上的社交平台,阅读那些看似有趣和有深度的文章时,在我们尽情享受互联网慷慨施舍的过程中,我们正在渐渐丧失深度阅读和深度思考的能力。 互联网鼓励我们蜻蜓点水般地从多种信息来源中广泛采集碎片化的信息,其伦理规范就是工业主义,这是一套速度至上、效率至上的伦理,也是一套产量最优化、消费最优化的伦理——如此说来,互......一起来看看 《浅薄》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

URL 编码/解码
URL 编码/解码

URL 编码/解码

html转js在线工具
html转js在线工具

html转js在线工具