全值匹配我最愛
最佳左字首法則，對於多列索引，查詢從最左前列開始，不跳過索引中的列
不在索引列上做任何操作，計算、函式、自動/手動型別轉換)，否則會導致索引失效導致全表掃瞄
儲存引擎不能使用索引中範圍條件右邊的列
盡量使用覆蓋索引（只訪問索引的查詢（索引列和查詢列一致）），減少select *
mysql在使用不等於（！=或者<>)的時候無法使用索引
is null，is not null也無法使用索引
like 以萬用字元開頭（『%abc…』）mysql索引失效會變成全表掃瞄的操作，如果非要使用』%…%'型別，可以採用索引覆蓋，這樣不會掃瞄全表，可以使用到索引
字串不加單引號索引失效
少用or，用它來連線時會索引失效
通過set slow_query_log=1 和slow_query_log_file=…file，開啟慢查詢後，可以通過設定long_query_time來指定慢查詢閾值，找到那些查詢比較慢的sql進行分析
一般來說，通過觀察、構建索引以及explain分析之後的能滿足大多數的優化條件，但是，有些時候也需要伺服器做一些調整，比如對於那些無法構建索引的，可以適當調整join buffer的大小。
當然通過set profiling=1開啟之後，可看到所有的sql語句都會被記錄到profiles中，然後對於每一條sql，通過select * from query id 可以看到該查詢的詳細資源使用情況然後做出相應的分析
通過開啟general_log=1，也是可以看到每一條sql的執行，然後記錄到mysql.general_log表中，生產環境一般不建議這樣用
mysql優化建議
1.建立 2.sql編寫mysql欄位型別 資料型別 含義date 3位元組，日期，格式 2014 09 18 time 3位元組，時間，格式 08 42 30 datetime 8位元組，日期時間，格式 2014 09 18 08 42 30 timestamp 4位元組，自動儲存記錄修改的時間 ...
MySQL優化建議
設計資料表的時候要遵守三正規化，但是不要嚴格遵守。可以適度打破正規化。乙個表字段不適合過多。常用表中只要保留常用的字段 盡量給每個字段新增not null 根據表的特點來選擇合適的表引擎，如果這個表經常被寫，應該選擇innodb,但是mysql5.6一般都是選擇innodb 根據表存放的資料來決定字...
mysql優化建議
sql優化判斷 1.首先是定位效率比較低的sql語句 2.使用explain分析低效sql的執行計畫 type const system 單錶中最多有乙個匹配行 type eq ref 使用唯一索引，對於每個索引鍵值，表中只有一條記錄匹配 type ref 使用的是非唯一索引或者字首索引掃瞄，返回匹...