EXPLAIN
先是最簡單的一個分析：
EXPLAIN(SELECT admin_name FROM w_admin )
這裏面顯示了查詢類型select_type爲簡單查詢，type指的是字段，possible_keys是指使用了哪個索引來進行搜索，key是指mysql實際使用的索引，key_len是指響應索引的長度，ref是指鏈接的匹配條件（例如外鍵查詢）：rows是指mysql根據統計信息以及索引選用的情況。
例如這樣一條關於管理員角色分配查詢的sql語句。
in查詢裏面不要包含太多的字段內容：
in實際上是用了數組來存儲裏面的字段信息的，如果這些數字都是連續的話，就建議不要用in了，用between會好些。
執行select語句的時候，儘量指明字段名稱
減少網絡的io耗損
當查詢數據只有一條的時候，儘量使用limit 1
這是爲了能夠使得EXPLAIN中的type列達到const類型
如果說sql語句進行排序的時候，儘量使得排序的關鍵字是索引字段
如果限制條件中其他字段沒有使用到索引，則儘量少用or
通常會用union all或者union來替代
union和union all的使用區別
前者在進行數據整合的時候會進行去重和重新排序，因此會消耗較多的cpu性能，所以使用的時候需要謹慎。(UNION ALL 查詢的時候沒有去重，所以可能會查詢出來多餘部分的數據)
隨機查詢的實現技巧
SELECT * from w_article ORDER BY RAND() limit 10
這種方式實現的隨機查詢一般性能消耗會比較大，不妨試試用limit來進行優化，limit的開始位置通過java或者php代碼，傳入相應的參數來進行設置。
常用的查詢關鍵字 in和exists的區別？
兩種關鍵字驅動的查詢順序有所不同，這也是性能變化的關鍵之處。
exists：外表驅動
in：內表驅動，先進行子查詢
優化可以考慮：
原SQL語句：
select colname … from A表 where a.id not in (select b.id from B表)
高效的SQL語句：
select colname … from A表 Left join B表 on where a.id = b.id where b.id is null
合理高效的分頁技巧：
通過一些limit來進行分頁的話，當數據量增大的時候，查詢會越來越慢。
不妨可以通過相應的id來進行起始點優化性能。不過這招很不靠譜。
儘量在where字句中用到null值，因爲這樣會放棄使用全表查詢
不建議使用%前綴模糊查詢
例如LIKE“%name”或者LIKE“%name%”，這種查詢會導致索引失效而進行全表掃描。但是可以使用LIKE “name%”。
那如何查詢%name%？
如下圖所示，雖然給secret字段添加了索引，但在explain結果並沒有使用：
那麼如何解決這個問題呢，答案：使用全文索引。
在我們查詢中經常會用到select id,fnum,fdst from dynamic_201606 where user_name like ‘%zhangsan%’; 。這樣的語句，普通索引是無法滿足查詢需求的。慶幸的是在MySQL中，有全文索引來幫助我們。（但是全文索引只在MYISAM裏能被支持）
創建全文索引的SQL語法是：
ALTER TABLE dynamic_201606 ADD FULLTEXT INDEX idx_user_name (user_name);
使用全文索引的SQL語句是：
select id,fnum,fdst from dynamic_201606 where match(user_name) against(‘zhangsan’ in boolean mode);
注意：在需要創建全文索引之前，請聯繫DBA確定能否創建。同時需要注意的是查詢語句的寫法與普通索引的區別。
在where字句中儘量少些一些對於字段的表達式操作，容易造成數據庫引擎放棄索引的操作
舉個例子來說：
select user_id,user_project from user_base where age*2=36;
中對字段就行了算術運算，這會造成引擎放棄使用索引，建議改成：
select user_id,user_project from user_base where age=36/2;
對於聯合索引來說，要遵守最左前綴法則
舉列來說索引含有字段id、name、school，可以直接用id字段，也可以id、name這樣的順序，但是name;school都無法使用這個索引。所以在創建聯合索引的時候一定要注意索引字段順序，常用的查詢字段放在最前面。
必要時可以使用force index來強制查詢走某個索引
有的時候MySQL優化器採取它認爲合適的索引來檢索SQL語句，但是可能它所採用的索引並不是我們想要的。這時就可以採用forceindex來強制優化器使用我們制定的索引。
當我們使用了範圍查詢的時候，聯合索引可能會失效
對於聯合索引來說，如果存在範圍查詢，比如between、>、<等條件時，會造成後面的索引字段失效。
LEFT JOIN A表爲驅動表，INNER JOIN MySQL會自動找出那個數據少的表作用驅動表，RIGHT JOIN B表爲驅動表。
