首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >mysqlbinlog命令详解记一次有函数的标量子查询导致的查询缓慢

mysqlbinlog命令详解记一次有函数的标量子查询导致的查询缓慢

作者头像
bsbforever
发布2020-08-19 15:53:32
发布2020-08-19 15:53:32
7220
举报

这个专题讲一些日常运维的异常处理

今天讲一个SQL 语句,他有很多标量子查询,其中有的是使用了函数

1. 现象

开发人员反映有条语句非常慢

2. 原因查找

2.1 查看整体执行计划

可以看出语句非常简单,由于 from后的表没有任何where条件

估算的是一行,实际看下了下有9000+的数据,单独查询1s不到

总体执行下来需要10分钟

接下来我们需要知道慢在哪里

2.2 找出慢的地方

这里我们采用笨的方法,注释掉其他的标量子查询只用其中一个

这时我们可以找出DCWIP.GET_WIRETYPE(CONTROL_LOT)这段占用了绝大多数的时间

到这里我们知道可能的原因是该语句循环执行了该函数近10000次导致

这里我们通过查看awr报告也证明了这点

2.3 优化函数

这时我们打开该函数,发现非常简单,里面有2个语句,将参数带进去,我们查看执行计划

可以看到其中有一个全表扫描,数据量3W比左右,执行时间0.03s

这里执行不频繁还好,如执行太多则会造成CPU大量消耗

接下来我们优化这个语句

我们有2种栏位选择 bdg_device 和 bdg_diepart

我们使用group by 查看 where栏位的分布情况

发现diepart 分布比较唯一

代码语言:javascript
复制
select BDG_DEVICE,count(*) from FWASSY.FWCATNS_AS_BONDINGDIAGRAM t group by BDG_DEVICE  order by count(*) desc 

这时我们在该栏位建索引

代码语言:javascript
复制
 create index  fwassy.BONDINGDIAGRAM_BDG_DEVICE on fwassy.FWCATNS_AS_BONDINGDIAGRAM(BDG_DEVICE)

之后看执行计划已经走索引了

3. 优化成果:

由于这是一个报表,还有其他语句,但是总体时间从原来的40分钟下降到15分钟

达到预期效果

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-05-17,如有侵权请联系 cloudcommunity@tencent.com 删除
目录
  • 1. 现象
  • 2. 原因查找
    • 2.1 查看整体执行计划
    • 2.2 找出慢的地方
    • 2.3 优化函数
  • 3. 优化成果:
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档