内容简介:本文讲述调整sql逻辑达到优化目的案例前面一篇文章说过在有赞的数据库运维体系里面,每个实例会部署相应的sql-killer工具,实时处理耗时比较长的查询。 业务方报执行某个功能时,系统报错
本文讲述调整 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——
以上所述就是小编给大家介绍的《业务优化案例一则》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 微服务架构案例(二):业务架构设计,系统分层管理
- 微服务架构案例(二):业务架构设计,系统分层管理
- 微服务架构案例(三):数据库选型简介,业务数据规划设计
- (译)Flutter中的响应式编程(Reactive Programming)、流(Streams)、业务逻辑组件(BloC)以及实际使用案例
- 中台之上(一):重视业务架构,不要让“业务的归业务、技术的归技术”
- 小程序多业务线融合【完整分包业务接入】
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
HTTPS权威指南
[英] Ivan Risti? / 杨洋、李振宇、蒋锷、周辉、陈传文 / 人民邮电出版社 / 2016-9 / 99.00元
本书是集理论、协议细节、漏洞分析、部署建议于一体的详尽Web应用安全指南。书中具体内容包括:密码学基础,TLS协议,PKI体系及其安全性,HTTP和浏览器问题,协议漏洞;最新的攻击形式,如BEAST、CRIME、BREACH、Lucky 13等;详尽的部署建议;如何使用OpenSSL生成密钥和确认信息;如何使用Apache httpd、IIS、Nginx等进行安全配置。一起来看看 《HTTPS权威指南》 这本书的介绍吧!