MySQL Sending data导致表查询慢的问题剖析

oneasp 发布于2019-07-31 17:32 / 1883人阅读

摘要：一事故现场上面的这条语句是一个联表分组查询语句。典型情况如查询包含可以按不同情况列出列的和子句时。相关文章实战导致查询很慢的问题详细分析索引无效且耗时巨大原因分析查询占用大量时间的问题处理堵塞和状态多，高详解执行计划详解

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

一、事故现场

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

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

执行结果：

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

怎么优化呢？

二、SQL语句分析三板斧 1、explain分析

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

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

执行结果：

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

在所有explain的结果中最重要的要数type/key/rows/extra这4个字段了,那接下来我着重在说一下这四个字段代表的意思及如何优化.

更多 explain 用法请看这篇文章：MYSQL explain详解

using temporary

using temporary 官方解释：”为了解决查询，MySQL需要创建一个临时表来容纳结果。典型情况如查询包含可以按不同情况列出列的GROUP BY和ORDER BY子句时。“”很明显就是通过where条件一次性检索出来的结果集太大了，内存放不下了，只能通过家里临时表来辅助处理。

EXPLAIN SELECT * FROM project AS p JOIN jmw_message.t_message AS t ON p.id = t.target_id

EXPLAIN SELECT * FROM project AS p JOIN jmw_message.t_message AS t ON p.id = t.target_id LIMIT 100

上面两条语句explain得到的结果是相同的，是因为他们的索引使用策略是相同的，即都没有很好的使用索引，（因为没有where条件和order by语句）但他们的最终耗时是不同的，很明显传输100条数据肯定要比传送1条数据慢。所以，最终耗时会在sending data（用show profile查看）上消耗的比例最大

2、show processlist

explain看不出问题，那到底慢在哪里呢？
于是想到了使用 show processlist 查看sql语句执行状态，查询结果如下：

发现很长一段时间，查询都处在 “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查看详细信息;

三、排查优化 1.排查对比

经过以上步骤，已经确定查询慢是因为大量的时间耗费在了Sending data状态上，结合Sending data的定义，将目标聚焦在查询语句的返回列上面
经过一一排查，最后定为到一个description的列上，这个列的设计为：descriptionvarchar(8000) DEFAULT NULL COMMENT "游戏描述",
于是采取了对比的方法，看看“不返回description的结果”如何。show profile的结果如下：

【解决方法】
找到了问题的根本原因，解决方法也就不难了。有几种方法：
1）查询时去掉description的查询，但这受限于业务的实现，可能需要业务做较大调整
2）表结构优化，将descripion拆分到另外的表，这个改动较大，需要已有业务配合修改，且如果业务还是要继续查询这个description的信息，则优化后的性能也不会有很大提升。

【索引优化】
有一个典型的优化就是与这个相关的：利用索引查询的时候不是有一个回表的概念吗，就是索引里面不能得到全部的列，因此需要回到原表里面获取，但是因为MySQL 5.6之前没有ICP（index condition pushdown）的概念，所以不能很好的利用索引，导致回表次数大增（实际上也就是一次query中sever端和storage端的交互太多，导致开销增大）。所以如果将索引的判断提前进行也就过滤掉了一些不必要回表的行，因此storage端传送给server端的不必要数据减少，开销减小。

相关文章：
实战：MySQL Sending data导致查询很慢的问题详细分析
mysql索引无效且sending data耗时巨大原因分析
mysql查询sending data占用大量时间的问题处理
mysql堵塞 sending data和sort状态多，cpu高
MYSQL explain详解
mysql explain执行计划详解

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/47391.html

一文看懂 MySQL 高性能优化技巧实践

摘要：实际应用中，查询的返回结果会有条记录。修改保存文件后，重启服务。通常优化至少到级别，最好能优化到指出使用哪个索引在该表找到行记录。如果该值为，说明没有使用索引，可以建立索引提高性能显示实际使用的索引。 ...

simon_chen 2021-09-08 09:36 评论0 收藏0
MySQL高性能学习笔记

摘要：高性能学习笔记。目前支持的数据库有和。超过强制中断。默认是最大质数发生器数量。默认是测试时内存块大小。默认是分布的随机数均匀分布高斯分布空间分布。 mysql 高性能学习笔记。一、Ubuntu 安装mysql 我们在Ubuntu环境下装一个测试用的MySQL来学习。 1.更新包 sudo apt-get update 2.安装MySQL的服务端和客户端 sudo apt-get in...

dongfangyiyu 2019-08-01 13:39 评论0 收藏0
Mysql 大数据操作状态查询

摘要：如果这个时候我们直接执行或者或者任何查询表的的语句的话，我们是不能得到任何结果的，因为在执行的时候，会把表锁起来。导致读取不到信息。导读在mysql运行的时候，我们希望能够查看到mysql的运行状态，尤其是在执行一些比较费时的操作的时候， msyql后台执行，却未显示任何信息，很让人着急，比如今天我把一个大的用户表(近千万级)导入到一个临时创建的表，使用insert into t...

cangck_X 2019-07-31 15:49 评论0 收藏0
一句 mysql#show processlist 引发的思想“革命”

摘要：因为大量的进程导致到达了系统的最大连接数，造成很多用户在排队等待的状态，系统会直接被拖垮。如果没有权限或者特殊情况设置这个值，也可以在程序中，根据需要，的时间大小来一些时间过长的进程释放掉。前几天在看一个亿级的视频中谈到mysql优化和解决的方案，其中说到一个命令 show processlist，由于对这个命令也是基于工作经验的普通使用，并没有深入研究，所以突然想深入了解下这个命令...

willin 2019-08-01 10:10 评论0 收藏0
SegmentFault 技术周刊 Vol.42 - MySQL：从删库到跑路

摘要：肖鹏微博数据库那些事儿肖鹏，微博研发中心技术经理，主要负责微博数据库相关的业务保障性能优化架构设计，以及周边的自动化系统建设。经历了微博数据库各个阶段的架构改造，包括服务保障及体系建设微博多机房部署微博平台化改造等项目。 showImg(https://segmentfault.com/img/bV24Gs?w=900&h=385); 对于手握数据库的开发人员来说，没有误删过库的人生是...

王陆宽 2019-08-06 14:09 评论0 收藏0