本文首發於個人微信公眾號《andyqian》，期待你的關注！

前言

有好幾天沒有寫文章了，實在不好意思。之前就有朋友希望我寫寫MySQL優化的文章。我遲遲沒有動筆，主要是因為，SQL優化這個東西，很廣，技巧也很多。自己在SQL優化方面的知識又還很欠缺。總覺得還不到分享的。思考許久，還是寫一篇文章，記錄一下。就算是拋磚引玉吧！

SQL優化

SQL優化是一個分析，優化，再分析，再優化的過程。站在執行計劃的角度來說，我們這個過程，就是在不斷的減少rows的數量。主要步驟有:

1. 通過explain 來檢視執行計劃。通過這一步驟，我們能夠分析出，該語句有沒有走索引，索引合不合理的重要依據。《讀懂MySQL執行計劃
   》
2. 縮小範圍。例如使用 < > ，between …and。來縮小掃描範圍。
   (對於該類，通常可優化於limit，時間範圍等SQL，而且非常有效)。
3. 減少連線數量 (對於連線查詢，我們必須儘可能減少每個子連線的結果集數量，只包含有效資料)。
4. 避免型別轉換。
   之前我們就談過，隱式型別轉換是最容易疏忽的慢SQL。如何避免？大家可以參考之前的文章《談談MySQL隱式型別轉換》。
5. 對於主鍵連續時而且允許的情況下，我們甚至可以使用max(id)來代替count(*)來統計使用者數。
6. 用 in 代替 or， 少用like，避免使用函式運算。

系統拆分

對於網際網路應用，特別是高併發應用來說，我們遇到多表連線導致慢SQL影響效能時。我們不應一味的追求在SQL上如何優化。更應該考慮這樣的設計是否合理，是否有拆分的可能性。所以，
我甚至認為：系統拆分才是解決慢SQL的終極方法。

報表庫

其實呀，有些SQL是無法再進行優化的，為什麼這麼說呢？沒有線上運算，沒有離線運算，統計報表如何出？在一定量級的資料表中，做統計報表。即使合理的索引，也會比較慢，這時建議將這些SQL放入特定的報表庫執行。以免造成主庫壓力。效能下降。對主流程造成影響。

結語

SQL優化是一個比較廣的話題且非常有意思的話。這篇文章主要給的是一些優化思路，不足的是並沒有給出更多的優化例項。等攢夠了優化例項，會再次分享出來。

最後：在留言區也分享一下你們SQL優化的思路唄～

 掃碼關注，一起進步