現在?？吹降奈恼戮褪荕ySQL性能優化，為什么需要優化呢？
因為：
- 數據庫出現瓶頸，系統的吞吐量出現訪問速度慢
- 隨著應用程序的運行，數據庫的中的數據會越來越多，處理時間變長
- 數據讀寫速度緩慢
總結：
like 前導符優化
like模糊查詢形如'%AAA%'和'%AAA'將不會使用索引，但是業務上不可避免可能又需要使用到這種形式。
通常的方法有兩種：
方案一：使用覆蓋索引，即查詢出的列只是用索引就可以獲取，而無須查詢表記錄，這樣也走了索引；
方案二：使用locate函數或者position函數代替like查詢，如table.field like '%AAA%'可以改為locate('AAA', table.field) > 0或POSITION('AAA' IN table.field)>0
in 和 exist
如果查詢的兩個表大小相當，那么用in和exists差別不大。如果兩個表中一個較小，一個是大表，則子查詢表大的用exists，子查詢表小的用in：例如：表A（小表），表B（大表）
示例一：
示例二：
not in 和 not exist
如果查詢語句使用了not in 那么內外表都進行全表掃描，沒有用到索引；而not exist 的子查詢依然能用到表上的索引。所以無論哪個表大，用not exists都比not in要快！
子查詢優化
1）MySQL 5.6 之前的版本對子查詢處理：不會將查詢的結果集計算出來用作與其他表做join,outer表每掃描一條數據，子查詢都會被重新執行一遍。
2）MySQL 5.6 對子查詢的處理 ：將子查詢的結果集 cache 到臨時表里，臨時表索引主要用來移除重復記錄，并且隨后也可能用于做join查詢，這種技術在 5.6 中叫做物化的子查詢，物化子查詢可以看到select_type字段為subquery，而在 5.5 里為DEPENDENT SUBQUERY。
3）子查詢一般都可以改成表的關聯查詢，子查詢會有臨時表的創建、銷毀，效率低下。
straight_join
mysql hint：mysql 優化器在處理多表的關聯的時候，很有可能會選擇錯誤的驅動表進行關聯，導致了關聯次數的增加，從而使得sql語句執行變得非常的緩慢。
這個時候需要有經驗的DBA進行判斷，選擇正確的驅動表，這個時候 straightjoin 就起了作用了，下面我們來看一看使用straight_join進行優化的案例。
嘗試采用user表做驅動表，使用straight_join強制連接順序：
高效分頁
1）傳統分頁
select * from table limit 10000,10
2）limit原理
- Limit 10000,10
- 偏移量越大則越慢
3）推薦分頁
復雜關聯SQL的優化
1、首先查詢返回的結果集，通常查詢返回的結果集很少，是有優化的空間的。
2、通過查看執行計劃，查看優化器選擇的驅動表，從執行計劃的rows可以大致反應出問題的所在。
3、搞清各表的關聯關系，查看關聯字段是否有合適的索引。
4、使用straight_join關鍵詞來強制調整驅動表的選擇，對優化的想法進行驗證。
5、如果條件允許，對復雜的SQL進行拆分。盡可能越簡單越好。
force index
有時優化器可能由于統計信息不準確等原因，沒有選擇最優的執行計劃，可以人為改變mysql的執行計劃，例如：
count的優化
按照效率排序的話，count(字段)<count(主鍵id)<count(1)≈count(*)，建議，盡量使用count(*)。
