這篇文章為大家帶來了關於mysql慢查詢優化的問題， 我會一步步帶大家分析SQL、檢查並優化，下面一起來看一下，希望對大家有幫助。
記一次mysql慢查詢最佳化－生產環境待辦事項清單現場示範5~6s才載入出來結果；頓時，產品經理的臉掛不住了，作為多年經驗的老開發，心想完犢子，臉啪啪滴。
不過，秉持著多年的江湖經驗，遇事不慌，拍個照先。
推薦學習：《MySQL影片教學》
第一步、分析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秒，另外此處，關聯表較多。
第二步、檢查索引，執行explain
當我們檢查索引發現re.incident_id和i.flow_id並沒有走索引，so，大喜，問題找到了，建索引；然而執行SQL，發現並卵！機智如我，直接打開explain，發現record的type為all，赤裸裸的沒走索引啊。
why?why?
第三步、檢查兩個關聯字段的字段類型、長度和字元類型是否一致
當比較字段類型和字段長度發現完全一致，短暫的鬱悶之後，發現了新的線索－
event表的id的字元類型為：
record表的incident_id的字元類型為：
果斷統一使用utf8mb4與項目組保持統一；再次explain，耗時瞬間低至1秒之內，手工。
第四步、強制使用索引運算
mysql在一個表如果索引基數過小的情況下預設會走全文搜索，所以對於表業務量過大，但是索引字段基本上為同一數據或null的情況還是需要在sql中寫死強制索引;在sql中使用強制索引解決辦法left join 後添加force index(alarm_id)——
第五步、IN通常是走索引的
只有當IN後面的資料在資料表中超過30% 的符合時是全表掃描，不走索引，因此IN走不走索引和後面的資料量有關係。 in大量資料可以使用left join來處理。
以上是遇事不慌，先記錄：mysql in慢查詢優化的詳細內容。更多資訊請關注PHP中文網其他相關文章！
