這兩天實習項目遇到一個網頁加載巨慢的問題(10多秒)，然后定位到是一個MySQL查詢特別慢的語句引起的：

SELECT *

FROM (

SELECT DISTINCT t.vc_date, t.c_bankno, t.vc_bankacco, t.vc_moneytype, t.en_totalbala

, t.en_usablebala, t1.vc_nameinbank, date_format(t.D_IMPORTTIME, '%Y-%m-%d %H:%i:%S') AS D_IMPORTTIME

, t.vc_fundcode, t.c_datamode, t.vc_taskid, t.id, t.vc_projectname

, t.vc_projectcode, t1.c_accotype

, (

SELECT IF(vc_occurtime IS NULL, DATE_FORMAT(vc_occurdate, '%Y-%m-%d'), DATE_FORMAT(CONCAT(vc_occurdate, vc_occurtime), '%Y-%m-%d %H:%i:%S')) AS tradeTime

FROM tbanktradedetail_view

WHERE vc_bankacco = t.vc_bankacco

) AS d_tradetime, t3.vc_entry_caption AS C_ACCOTYPE_STR, t5.vc_entry_caption AS VC_BANKNAME, t4.vc_entry_caption AS VC_MONEYTYPE_STR

FROM tbankaccobala t

INNER JOIN tbankaccoinfo t1 ON t.vc_bankacco = t1.vc_bankacco

INNER JOIN (

SELECT vc_entry_value, vc_entry_caption

FROM ot_dic_tdictionaryentry

WHERE vc_entry_no = '5087'

) t3

ON t1.c_accotype = t3.vc_entry_value

INNER JOIN (

SELECT vc_entry_value, vc_entry_caption

FROM ot_dic_tdictionaryentry

WHERE vc_entry_no = '1004'

) t4

ON t1.VC_MONEYTYPE = t4.vc_entry_value

INNER JOIN (

SELECT vc_entry_value, vc_entry_caption

FROM ot_dic_tdictionaryentry

WHERE vc_entry_no = '1014'

) t5

ON t.c_bankno = t5.vc_entry_value

WHERE 1 = 1

AND t.id IN (

-- this query will take 4.6s:

-- SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1)

-- FROM tbankaccobala

-- GROUP BY vc_bankacco

-- but the following query only takes 1.1s:

SELECT hhhh from(

SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1) as hhhh

FROM tbankaccobala

GROUP BY vc_bankacco

) as sbstr

-- 對IN的子查詢做二次查詢

)

) t

WHERE 1 = 1

ORDER BY t.D_IMPORTTIME DESC

抽出查詢慢關鍵部分：

SELECT *

FROM (

SELECT DISTINCT t.vc_date, t.c_bankno, t.vc_bankacco, t.vc_moneytype, t.en_totalbala

-- 此處省略選擇多個列語句

FROM tbankaccobala t

-- 此處省略多張表連表查詢語句

WHERE 1 = 1

AND t.id IN (

-- 這個查詢需要3s:

SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1)

FROM tbankaccobala

GROUP BY vc_bankacco

)

) t

這個語句導致前端頁面10多秒才有響應(但MySQL執(zhí)行顯示要4.6秒，phpMyAdmin也是10秒左右響應，為何？)

IN子查詢語句優(yōu)化

把IN語句里面的內容改成下面這樣，只在外層再加一個select，就把3s的查詢縮短為0.006s:

SELECT hhhh from(

SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1) as hhhh

FROM tbankaccobala

GROUP BY vc_bankacco

) as sbstr

-- 對IN的子查詢做二次select，或者把IN改為JOIN都可以解決速度奇慢的問題

原語句空行處省略了一系列的其他表和 INNER JOIN 語句。一開始懷疑是多表的JOIN操作導致速度變慢，但刪去JOIN變成上面這段注釋掉的語句之后，速度依然非常慢，顯示要3s，于是猜測 IN 才是導致速度變慢的主要因素，改后只要0.006s，嘖…

EXPLAIN 未優(yōu)化的語句：

(相關子查詢是使用外部查詢中的值的子查詢)

EXPLAIN 優(yōu)化的語句：

我的理解：優(yōu)化前，子查詢是相關子查詢，對于外部產生的每個值，都要執(zhí)行一次子查詢；優(yōu)化后，子查詢不再是相關子查詢，只需要執(zhí)行一次子查詢并緩存中間結果，外部查到的每個值去緩存的中間結果里比對一下就行了。

(有人說是能不能用索引的原因——這么說應該是不對的)

完整查詢的后端響應速度對比：

前：

后：

索引優(yōu)化

對于這么小的數據規(guī)模，時間還是太長了… 看前面explain執(zhí)行計劃的截圖，嗯，沒有索引…

給t1的vc_bankacco加上索引之后

解釋執(zhí)行計劃：

查詢和網頁響應用時大幅縮短：

再看sql里還有三個join：

用的都是ot_dic_tdictionaryentry這張表的t4.vc_entry_value字段，那么試著給這個字段也加上索引吧，然后用時如下：

是的，時間反而變長了！

explain執(zhí)行計劃：

所以變慢原因是：

沒加vc_entry_value的索引時，會先用vc_entry_no選出一個數量很小的表，再和t1做join，

而加了vc_entry_value的索引之后，MySQL就把這個索引用了起來，join語句被優(yōu)化為先FirstMatch(ot_dic_tdictionaryentry)，這產生了一個1713*1713=2934369行的中間結果(笛卡爾乘積)，然后才使用vc_entry_no進行where過濾。

所以索引不能亂加啊，加錯了反而會導致性能下降！這個示例里的查詢要加索引只能在vc_entry_no上索引，而不能在vc_entry_value上！

這個示例中主要提升是IN子查詢語句的優(yōu)化。在使用索引的情況下，對IN子查詢做優(yōu)化前后的查詢時間分別是3.1s和0.16s

總結

以上是生活随笔為你收集整理的mysql in优化_MySQL的一次优化记录 （IN子查询和索引优化）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。