mysql?in索引慢查詢優(yōu)化實現(xiàn)步驟解析

更新時間：2023年05月12日 10:42:32 作者：刨紅薯的小羊竿爾

這篇文章主要為大家介紹了mysql?in慢查詢優(yōu)化實現(xiàn)步驟的示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

記一次mysql慢查詢優(yōu)化

生產(chǎn)環(huán)境待辦列表現(xiàn)場演示5~6s才加載出來結果；頓時，產(chǎn)品經(jīng)理的臉掛不住了，作為多年經(jīng)驗的老開發(fā)，心想完犢子，臉啪啪滴。

不過，秉著多年的江湖經(jīng)驗，遇事不慌，拍個照先。

第一步、分析SQL

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量條件)***

當flow_id in接入大量條件，sql直接變慢，由之前的80ms到5.8秒，另外此處，關聯(lián)表較多。

第二步、檢查索引，執(zhí)行explain

當我們檢查索引發(fā)現(xiàn)re.incident_id和i.flow_id并沒有走索引，so，大喜，問題找到了，建索引；然而執(zhí)行SQL，發(fā)現(xiàn)并卵！機智如我，直接打開explain，發(fā)現(xiàn)record的type為all，赤裸裸的沒走索引啊。

why?why?

第三步、檢查兩個關聯(lián)字段的字段類型、長度和字符類型是否一致

當比較字段類型和字段長度發(fā)現(xiàn)完全一致，短暫的郁悶之后，發(fā)現(xiàn)了新的線索——

event表的id的字符類型為：

record表的incident_id的字符類型為：

果斷統(tǒng)一使用utf8mb4與項目組保持統(tǒng)一；再次explain，耗時瞬間低至1秒之內(nèi)，手工。

第四步、強制使用索引操作

mysql在一個表如果索引基數(shù)過小的情況下默認會走全文搜索，所以對于表業(yè)務量過大，但是索引字段基本上為同一數(shù)據(jù)或null的情況還是需要在sql中寫死強制索引;在sql中使用強制索引解決辦法 left join 后添加 force index(alarm_id)——