第一:選擇唯一性索引
唯一性索引的值是唯一的,可以更快捷的通過該索引來確定某條記錄.
2.索引的列為where 後面經常作為條件的字段建立索引
如果某個字段經常作為查詢條件,而且又有較少的重複列或者是唯一咧可以考慮作為索隱列
經常作為查詢條件的列作為索引會提高速度
3.位經常需要進行排序.分組和聯合操作的的字段建立索引.
order by group by distinct union
這種情況下在查詢的時候排序會浪費很多的時間,
如果為其建立索引可以有效的避免排序操作.
4.限制索引的的數目,索引的數目多,對系統的資源也是一種消耗,刪除修改也會費資源.
5.勁量使用資料量少的索引. 或者索引字首索引.
如果索引的值很長, 查詢速度就會受到影響.
6．盡量使用字首來索引
如果索引欄位的值很長，最好使用值的字首來索引。例如，text和blog型別的字段，進行全文檢索
會很浪費時間。如果只檢索欄位的前面的若干個字元，這樣可以提高檢索速度。
7.刪除不再使用的索引.資料或者業務變更,資料方式變更就需要,刪除無用的索引.
8.小表不應該建立索引.
這篇文章主要記錄，我對如何找未使用索引的理解及風險(目前還未找到理想方法)，能像oracle儲存執行計畫，根據執行計畫(v$sql_plan)來判斷索引使用情況是比較安全。當然oracle的index monitor特性類似percona的userstat有比較大的風險。
以下四個工具(方法)是在mysql找未使用索引比較方便，但都存在一定風險
1、mysqlidxchx
2、pt-index-usage
3、userstat
4、check-unused-keys
1、mysqlidxchx工具很長時間沒有更新，但主要用來分析general log、slow.log，來判斷例項中那個索引是可以刪除，但這個工具沒有經過實戰，風險很大。
2、pt-index-usage原理來類似mysqlidxchx，執行過程中效能消耗比較嚴重，如果要在生產庫上部署，最好在凌晨業務低鋒時使用，pt-index-usage只支援slow.log格式的檔案，如果要全面分析整個例項索引使用情況，需要long_query_time設定成0，才能把所以的sql記錄下來，但同時會對磁碟空間造成壓力，同時pt-index-usage對大檔案分析就是件痛苦的事。當然pt-index-usage可以考慮部分表索引使用情況的確認。
3、最看好的userstat，收集資訊效能優越，成本低。這個patch是google貢獻的(userstat_running)，percona把它改名成userstat，預設是不開啟的，開啟是會收集客戶端、索引、表、執行緒資訊儲存在client_statistics、index_statistics、table_statistics、thread_statistics。userstat的bug導致的問題太嚴重，直接導致mysql crash，到目前**生產環境還沒有使用。
4、ryan lowe的check-unused-keys指令碼基於userstat，能夠比較方便輸出需要刪除的索引。
小結：mysql能把每條sql執行計畫儲存在效能檢視中，寫入效能檢視成本是非常小，使用者可以根據執行計畫來判斷索引使用情況，分析執行計畫突變的監控。
簡單記憶建議索引的原則是 :唯一列 經常被查詢 排序 預先建立索引 總體控制數量 使用欄位少的列索引 字首索引 刪除無用 小表不建
不走索引的原因:
1.沒有查詢條件沒where 後面的內容 查詢條件沒索引
2.查詢條件沒引導列. 沒有有索引的列
3.查詢數量是超過表的一部分,mysql30%,oracle 20%
4.索引失效,索引插入過多可能發生意外失效
5.查詢條件使用函式在索隱列上面.計算等.
查詢條件使用函式在索引列上，或者對索引列進行運算，運算包括(+，-，*，/，! 等)
錯誤的例子：select * from test where id-1=9; 正確的例子：select * from test where id=10;
6.對小表查詢
7.統計資料不真實.
8.cbo計算走索引花費過大的情況
9查詢條件字串和數字等的隱式轉換.
10.!= <>
11.%% 兩個百分號不走索引,開始的結尾的百分號走索引.
14 not in not exist in 勁量轉換為union
15, time 和date 時間格式不一致
16.17,b-tree索引is null不會走,is not null會走,位圖索引 is null,is not null 都會走
索隱列避免空列,一般選非空的列.
myisam 儲存引擎索引鍵長度總和不能超過1000 位元組；
blob 和text 型別的列只能建立字首索引；
mysql 目前不支援函式索引；
使用不等於（!= 或者<>）的時候mysql 無法使用索引；
過濾字段使用了函式運算後（如abs(column)），mysql 無法使用索引；
join 語句中join 條件字段型別不一致的時候mysql 無法使用索引；
使用like 操作的時候如果條件以萬用字元開始（ '%abc...'）mysql 無法使用索引；
使用非等值查詢的時候mysql 無法使用hash 索引；
在我們使用索引的時候，需要注意上面的這些限制，
尤其是要注意無法使用索引的情況，因為這很容易讓我們因為疏忽而造成極大的效能隱患。
mysql索引優化原則 MySQL 索引優化原則
索引優化原則 1 最左字首匹配原則，聯合索引，mysql會從做向右匹配直到遇到範圍查詢 3 and d 4 如果建立 a,b,c,d 順序的索引，d是用不到索引的，如果建立 a,b,d,c 的索引則都可以用到，a,b,d的順序可以任意調整。2 和in可以亂序，比如a 1 and b 2 and c ...
mysql索引優化原則 MySQL索引優化
mysql官方對索引的定義 索引是幫助mysql高效獲取資料的資料結構。索引是在儲存引擎中實現的，所以每種儲存引擎中的索引都不一樣。如myisam和innodb儲存引擎只支援btree索引 memory和heap儲存引擎可以支援hash和btree索引。這裡僅針對常用的innodb儲存引擎所支援的b...
mysql 新增索引原則 mysql建立索引的原則
在mysql中使用索引的原則有以下幾點 1 對於查詢頻率高的字段建立索引 2 對排序 分組 聯合查詢頻率高的字段建立索引 3 索引的數目不宜太多 原因 a 每建立乙個索引都會占用相應的物理控制項 b 過多的索引會導致insert update delete語句的執行效率降低 4 若在實際中，需要將多...