业务优化案例一则

栏目: 数据库 · 发布时间: 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——

业务优化案例一则


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

查看所有标签

猜你喜欢:

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

HTTPS权威指南

HTTPS权威指南

[英] Ivan Risti? / 杨洋、李振宇、蒋锷、周辉、陈传文 / 人民邮电出版社 / 2016-9 / 99.00元

本书是集理论、协议细节、漏洞分析、部署建议于一体的详尽Web应用安全指南。书中具体内容包括:密码学基础,TLS协议,PKI体系及其安全性,HTTP和浏览器问题,协议漏洞;最新的攻击形式,如BEAST、CRIME、BREACH、Lucky 13等;详尽的部署建议;如何使用OpenSSL生成密钥和确认信息;如何使用Apache httpd、IIS、Nginx等进行安全配置。一起来看看 《HTTPS权威指南》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具