[原則一:選擇需要優化的SQL]

1,選擇需要優化的SQL:不是所有的SQL都需要優化,在優化的過程中,首選更需要優化的SQL;
   怎麽選擇?優先選擇優化高並發低消耗的SQL；
  1，1小時請求1W次，1次10個IO；
  2，1小時請求10次，1次1W個IO；
    考慮:
    ①,從單位時間產生的IO總數來說,相同的;
    ②,針對一個SQL,如果我能把10個IO變成7個IO,一小時減少3W個IO;
        針對第二個SQL,如果能把1W個IO變成7K個IO,一小時減少3W個IO;
    ③,從優化難度上講,1W->7K難的多;
    ④,從整體性能上來說,第一個SQL的優化能夠極大的提升系統整體的性能;第二個SQL慢一點,無非也就是10個連接查詢慢一點;

 
2，定位性能瓶頸；
    1，SQL運行較慢有兩個影響原因，IO和CPU，明確性能瓶頸所在；
    2，明確優化目標；

[原則二:從Explain和Profile入手]

1，任何SQL的優化，都從Explain語句開始；Explain語句能夠得到數據庫執行該SQL選擇的執行計劃； 
2，首先明確需要的執行計劃，再使用Explain檢查； 
3，使用profile明確SQL的問題和優化的結果；

[原則三:永遠用小結果集驅動大的結果集]

 註意不是：小表連接大的快，而是結果集 

[原則四:在索引中完成排序]

[原則五:使用最小Columns]

1，減少網絡傳輸數據量； 
2，特別是需要使用column排序的時候.為什麽?MYSQL排序原理，是把所有的column數據全部取出，在排序緩存區排序，再返回結果；
   如果column數據量大，排序區容量不夠的時候，就會使用先column排序，再取數據，再返回的多次請求方式；

[原則六:使用最有效的過濾條件]

1，過多的WHERE條件不一定能夠提高訪問性能； 
2，一定要讓where條件使用自己預期的執行計劃；

[原則七:避免復雜的JOIN和子查詢]

1，復雜的JOIN和子查詢，需要鎖定過多的資源，MYSQL在大量並發情況下處理鎖定性能下降較快； 
2， 不要過多依賴SQL的功能，把復雜的SQL拆分為簡單的SQL； 
3，MySQL子查詢性能較低，應盡量避免使用；

SQL優化原則