通過(guò)一個(gè)實(shí)例給大家分享了MySQL Sending data表查詢慢問(wèn)題解決辦法。

最近在代碼優(yōu)化中，發(fā)現(xiàn)了一條sql語(yǔ)句非常的慢，于是就用各種方法進(jìn)行排查，最后終于找到了原因。

一、事故現(xiàn)場(chǎng)

上面的這條語(yǔ)句是一個(gè)聯(lián)表分組查詢語(yǔ)句。

執(zhí)行結(jié)果：

我們可以看到，這條語(yǔ)句用了 1.300 秒, 而 Sending data 就用了 1.28 秒，占用了將近 99% 的時(shí)間，所以，我們對(duì)這個(gè)進(jìn)行優(yōu)化。

怎么優(yōu)化呢？

二、SQL語(yǔ)句分析三板斧

1、explain分析

對(duì)上邊的語(yǔ)句進(jìn)行 explain 分析：

執(zhí)行結(jié)果：

通過(guò)explain, 我們可以看到上邊的語(yǔ)句，有用到索引key。

2、show processlist

explain看不出問(wèn)題，那到底慢在哪里呢？

于是想到了使用 show processlist 查看sql語(yǔ)句執(zhí)行狀態(tài)，查詢結(jié)果如下：

發(fā)現(xiàn)很長(zhǎng)一段時(shí)間，查詢都處在 “Sending data”狀態(tài)

查詢一下“Sending data”狀態(tài)的含義，原來(lái)這個(gè)狀態(tài)的名稱很具有誤導(dǎo)性，所謂的“Sending data”并不是單純的發(fā)送數(shù)據(jù)，而是包括“收集 + 發(fā)送 數(shù)據(jù)”。

這里的關(guān)鍵是為什么要收集數(shù)據(jù)，原因在于：mysql使用“索引”完成查詢結(jié)束后，mysql得到了一堆的行id，如果有的列并不在索引中，mysql需要重新到“數(shù)據(jù)行”上將需要返回的數(shù)據(jù)讀取出來(lái)返回個(gè)客戶端。

3、show profile

為了進(jìn)一步驗(yàn)證查詢的時(shí)間分布，于是使用了 show profile 命令來(lái)查看詳細(xì)的時(shí)間分布

首先打開(kāi)配置：set profiling=on;