通过一个实例给大家分享了MySQL Sending data表查询慢问题解决办法。 最近在代码优化中，发现了一条sql语句非常的慢，于是就用各种方法进行排查，最后终于找到了原因。 [b]一、事故现场 [/b] 上面的这条语句是一个联表分组查询语句。 执行结果： [img]http://files.jb51.net/file_images/article/201712/2017120716492865.png[/img] 我们可以看到，这条语句用了 [code]1.300[/code] 秒, 而 [code]Sending data[/code] 就用了 [code]1.28[/code] 秒，占用了将近 99% 的时间，所以，我们对这个进行优化。 怎么优化呢？ [b]二、SQL语句分析三板斧[/b] 1、explain分析 对上边的语句进行 [code]explain[/code] 分析： 执行结果： [img]http://files.jb51.net/file_images/article/201712/2017120716492966.png[/img] 通过[code]explain[/code], 我们可以看到上边的语句，有用到索引[code]key[/code]。 2、show processlist explain看不出问题，那到底慢在哪里呢？ 于是想到了使用 [code]show processlist[/code] 查看sql语句执行状态，查询结果如下： [img]http://files.jb51.net/file_images/article/201712/2017120716492967.png[/img] 发现很长一段时间，查询都处在 “Sending data”状态 查询一下“Sending data”状态的含义，原来这个状态的名称很具有误导性，所谓的“Sending data”并不是单纯的发送数据，而是包括“收集 + 发送 数据”。 这里的关键是为什么要收集数据，原因在于：mysql使用“索引”完成查询结束后，mysql得到了一堆的行id，如果有的列并不在索引中，mysql需要重新到“数据行”上将需要返回的数据读取出来返回个客户端。 3、show profile 为了进一步验证查询的时间分布，于是使用了 [code]show profile[/code] 命令来查看详细的时间分布 首先打开配置：set profiling=on; 执行完查询后，使用show profiles查看query id; 使用show profile for query query_id查看详细信息; [b]三、排查优化 [/b] 1.排查对比 经过以上步骤，已经确定查询慢是因为大量的时间耗费在了Sending data状态上，结合Sending data的定义，将目标聚焦在查询语句的返回列上面 经过一 一排查，最后定为到一个description的列上，这个列的设计为：[code]description[/code]varchar(8000) DEFAULT NULL COMMENT '游戏描述', 于是采取了对比的方法，看看“不返回description的结果”如何。show profile的结果如下： 【解决方法】 找到了问题的根本原因，解决方法也就不难了。有几种方法： 1）查询时去掉description的查询，但这受限于业务的实现，可能需要业务做较大调整 2）表结构优化，将descripion拆分到另外的表，这个改动较大，需要已有业务配合修改，且如果业务还是要继续查询这个description的信息，则优化后的性能也不会有很大提升。