溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“mysql in慢查詢如何優化”，在日常操作中，相信很多人在mysql in慢查詢如何優化問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”mysql in慢查詢如何優化”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
第一步、分析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，赤裸裸的沒走索引啊。
第三步、檢查兩個關聯字段的字段類型、長度和字符類型是否一致
當比較字段類型和字段長度發現完全一致，短暫的郁悶之后，發現了新的線索——
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慢查詢如何優化”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
