淺談MySQL SQL優化

本文首發於我的微信公衆號《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優化的思路唄～

相關閱讀:

談談MySQL顯示類型轉換

寫會MySQL索引

MySQL表設計踩過的坑！

淺談MySQL表結構設計

 

 掃碼關注，一塊兒進步

我的博客: http://www.andyqian.com