通過一個例項給大家分享了MySQL Sending data表查詢慢問題解決辦法。

最近在程式碼優化中，發現了一條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.size_id

執行結果：

通過explain,我們可以看到上邊的語句，有用到索引key。

2、show processlist

explain看不出問題，那到底慢在哪裡呢？

於是想到了使用 show processlist

發現很長一段時間，查詢都處在 “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的資訊，則優化後的效能也不會有很大提升。