mysql in慢查詢?nèi)绾蝺?yōu)化

這篇文章主要介紹“mysql in慢查詢?nèi)绾蝺?yōu)化”，在日常操作中，相信很多人在mysql in慢查詢?nèi)绾蝺?yōu)化問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”mysql in慢查詢?nèi)绾蝺?yōu)化”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

第一步、分析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 (大量條件)***復(fù)制代碼

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

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

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

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

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

event表的id的字符類型為：

record表的incident_id的字符類型為：

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

第四步、強(qiáng)制使用索引操作

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

第五步、IN通常是走索引的

只有當(dāng)IN后面的數(shù)據(jù)在數(shù)據(jù)表中超過(guò)30% 的匹配時(shí)是全表掃描，不走索引，因此IN走不走索引和后面的數(shù)據(jù)量有關(guān)系。 in大量數(shù)據(jù)可以使用left join來(lái)處理。

到此，關(guān)于“mysql in慢查詢?nèi)绾蝺?yōu)化”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！