前言
之前開發項目的過程當中數據庫存儲的數據量都不是很大，在表的設計當中就只有一個主鍵索引。很少接觸到數據庫的索引，SQL 優化這些東西。公司目前的項目數據達到了百萬級別了，讓我優化一下慢 SQL，之前是懂一些 SQL 優化和索引相關的理論知識，沒有實際操作過，特此記錄優化的過程和思路，事實證明，理論和實操還是有不少區別的。
理論知識
- SQL 的優化大部分都是和索引相關，所以對索引的相關知識一定要有很深的理解。網上關於索引的文章很多，這裏推薦一篇比較好的文章：MySQL性能優化之索引優化
- SQL的優化也有對本身SQL代碼的優化。比如 not in 和exists這種。詳見： sql優化的幾種方法
- EXPLAIN 語句的運用和了解：MySQL Explain詳解
- 運行SQL，總得有一個執行的順序吧？SQL語句執行順序
實際過程
理論是基礎，在實際的過程當中需要靈活的運用。特此記錄自己在進行優化時的一些操作和心得。
- 查看執行語句選擇的索引，一次查詢只會選擇一個索引，是mysql自動進行的選擇。 但是mysql並不會總是選擇我們希望的索引。所以要結合索引的相關知識讓mysql選擇到我們希望的索引。
- 在1的基礎上，需要注意，當我們新建一條索引之後，可能會導致之前某些SQL在索引的選擇上發生變化。
- 結合業務場景進行SQL方面的優化，當需要連表進行count操作的時候，如果兩張表的數據都很大的話，可以先考慮group by 在用sum統計！等等之類的操作（需要查看大量理論相關的知識）
- 索引不是越多越好，合理的索引會加快查詢效率，不合理的索引也可能會加快效率，但是會提高維護成本！
- 光有索引也不行，還得結合SQL進行優化，思考爲什麼慢，慢的原因可以避免麼？慢的sql可以變換麼？。
- 考慮SQL當中的某個操作是否可以避免，或者替換，比如：存在聯合唯一索引：dept_id和user_id，那麼當dept_id爲查詢條件的時候，對user_id的去重操作就可以取消掉。
- 如果SQL上優化不了，那就從業務上優化。
- 最後一定要有耐心，優化的過程是很枯燥的！！！！！
注意點
- 保證測試環境和正式環境的數據，SQL，機器配置一致。
- 有時可能是正式環境進行了限流操作，結果本地跑的飛起，正式卡的飛起。