mysql?in索引慢查詢優(yōu)化實現(xiàn)步驟解析
記一次mysql慢查詢優(yōu)化
生產環(huán)境待辦列表現(xiàn)場演示5~6s才加載出來結果;頓時,產品經理的臉掛不住了,作為多年經驗的老開發(fā),心想完犢子,臉啪啪滴。
不過,秉著多年的江湖經驗,遇事不慌,拍個照先。
第一步、分析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秒之內,手工。
第四步、強制使用索引操作
mysql在一個表如果索引基數過小的情況下默認會走全文搜索,所以對于表業(yè)務量過大,但是索引字段基本上為同一數據或null的情況 還是需要在sql中寫死強制索引;在sql中使用強制索引解決辦法 left join 后添加 force index(alarm_id)——
第五步、IN通常是走索引的
只有當IN后面的數據在數據表中超過30% 的匹配時是全表掃描,不走索引,因此IN走不走索引和后面的數據量有關系。 in大量數據可以使用left join來處理。
以上就是mysql in慢查詢優(yōu)化的詳細內容,更多關于mysql in慢查詢優(yōu)化的資料請關注腳本之家其它相關文章!
相關文章
deepin20.1系統(tǒng)安裝MySQL8.0.23(超詳細的MySQL8安裝教程)
這篇文章主要介紹了deepin20.1系統(tǒng)安裝MySQL8.0.23(最美國產Liunx系統(tǒng),最詳細的MySQL8安裝教程),本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-01-01