這是一條SQL的執行順序

可以看到JOIN和WHERE在早期執行，所以優化的重點往往也在這裡。資料庫的查詢效能一般受CPU檢索能力+I/O裝置的讀寫速度影響，所以要提高查詢效能最簡單粗暴的方式就是 換更強的CPU（這樣邏輯判斷就更快），或者增加儲存裝置的效能（例如機械盤換SSD）。這種方式有點類似於以力破巧，簡單粗暴有效果。

當硬體都沒法再提高的情況下，就要從思路上來解決問題了。索引就是一個簡單的提高查詢效能的方法，具體原理就是把關鍵資料的位置單獨儲存一下，類似於一本書的目錄，沒有目錄的時候找一篇文章需要翻遍整本書，但是有目錄了以後，就可以根據目錄直接翻到對應頁碼。不過要注意，索引也是有副作用的，首先是降低寫入效能，因為製作目錄需要單獨的計算，還有就是不要濫用索引，只索引最需要的欄位（往往是查詢條件最常見的欄位），這裡還有聯合索引的概念，就不具體展開了。

根據執行順序，要小心的考慮join的方向（不同的join出來的結果不同），要join出來（能夠包含查詢需要的資料）最小的結果集，這樣CPU的效能就會減少浪費。然後是仔細斟酌where的條件，也是避免無端的CPU效能浪費，原則就是儘可能在早期篩掉明顯不符合查詢條件的結果，減少CPU判斷次數。

GROOUP BY和HAVING也是比較早期的執行過程，所以要慎用，這個非常影響效能，不過好在它在where之後，如果在where之前，那就是個災難了，在對全部資料集做分組，不敢想象會有多慢。

SELECT以前不太建議條件直接用 * 但現在基本沒問題了 ,查詢優化器會自動優化了。
所以優化SQL的整體方向就是，減少硬體的讀寫和判斷，儘可能在早期篩掉無效結果，減少結果集的大小
但這個想法如果不經過實踐應該會比較難理解，需要在具體工作中多分析思考嘗試。