gpt4 book ai didi

深入分析MySQL Sending data查询慢问题

转载 作者:qq735679552 更新时间:2022-09-29 22:32:09 25 4
gpt4 key购买 nike

CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章深入分析MySQL Sending data查询慢问题由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.

通过一个实例给大家分享了MySQL Sending data表查询慢问题解决办法.

最近在代码优化中,发现了一条sql语句非常的慢,于是就用各种方法进行排查,最后终于找到了原因.

1、事故现场 。

?
1
2
3
4
SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1
GROUP BY og.color_id, og.size_id

上面的这条语句是一个联表分组查询语句.

执行结果:

深入分析MySQL Sending data查询慢问题

我们可以看到,这条语句用了 1.300 秒, 而 Sending data 就用了 1.28 秒,占用了将近 99% 的时间,所以,我们对这个进行优化.

怎么优化呢?

2、SQL语句分析三板斧 。

1、explain分析 。

对上边的语句进行 explain 分析:

?
1
2
3
4
explain SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1
GROUP BY og.color_id, og.size_id

  。

执行结果:

深入分析MySQL Sending data查询慢问题

通过explain, 我们可以看到上边的语句,有用到索引key.

2、show processlist 。

explain看不出问题,那到底慢在哪里呢?

于是想到了使用 show processlist 查看sql语句执行状态,查询结果如下:

深入分析MySQL Sending data查询慢问题

发现很长一段时间,查询都处在 “Sending data”状态 。

查询一下“Sending data”状态的含义,原来这个状态的名称很具有误导性,所谓的“Sending data”并不是单纯的发送数据,而是包括“收集 + 发送 数据”.

这里的关键是为什么要收集数据,原因在于:mysql使用“索引”完成查询结束后,mysql得到了一堆的行id,如果有的列并不在索引中,mysql需要重新到“数据行”上将需要返回的数据读取出来返回个客户端.

3、show profile 。

为了进一步验证查询的时间分布,于是使用了 show profile 命令来查看详细的时间分布 。

首先打开配置:set profiling=on,

执行完查询后,使用show profiles查看query id,

使用show profile for query query_id查看详细信息,

3、排查优化 。

1.排查对比 。

经过以上步骤,已经确定查询慢是因为大量的时间耗费在了Sending data状态上,结合Sending data的定义,将目标聚焦在查询语句的返回列上面 。

经过一 一排查,最后定为到一个description的列上,这个列的设计为:descriptionvarchar(8000) DEFAULT NULL COMMENT '游戏描述'.

于是采取了对比的方法,看看“不返回description的结果”如何。show profile的结果如下:

【解决方法】 。

找到了问题的根本原因,解决方法也就不难了。有几种方法:

1)查询时去掉description的查询,但这受限于业务的实现,可能需要业务做较大调整 。

2)表结构优化,将descripion拆分到另外的表,这个改动较大,需要已有业务配合修改,且如果业务还是要继续查询这个description的信息,则优化后的性能也不会有很大提升.

原文链接:https://segmentfault.com/a/1190000012326158 。

最后此篇关于深入分析MySQL Sending data查询慢问题的文章就讲到这里了,如果你想了解更多关于深入分析MySQL Sending data查询慢问题的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com