1.1、索引選擇原則
較頻繁的作為查詢條件的字段應該建立索引
唯一性太差的字段不適合單獨建立索引，即使頻繁作為查詢條件
更新非常頻繁的字段不適合建立索引
不會出現在 where 子句中的字段不該建立索引
1.2、索引選擇原則描述
1.3、索引選擇注意事項
既然索引可以加快查詢速度，那麼是不是只要是查詢語句需要，就建上索引？答案是否定的。因為索引雖然加快了查詢速度，但索引也是有代價的：索引檔案本身要消耗儲存空間，同時索引會加重插入、刪除和修改記錄時的負擔，另外，mysql在執行時也要消耗資源維護索引，因此索引並不是越多越好。
一般兩種情況下不建議建索引：
表記錄比較少，例如一兩千條甚至只有幾百條記錄的表，沒必要建索引，讓查詢做全表掃瞄就好了;
至於多少條記錄才算多，這個個人有個人的看法，我個人的經驗是以2000作為分界線，記錄數不超過 2000可以考慮不建索引，超過2000條可以酌情考慮索引。
索引的選擇性較低。所謂索引的選擇性（selectivity），是指不重複的索引值（也叫基數，cardinality）與表記錄數（#t）的比值：
index selectivity = cardinality / #t
顯然選擇性的取值範圍為(0, 1]，選擇性越高的索引價值越大，這是由b+tree的性質決定的。例如，上文用到的employees.titles表，如果title欄位經常被單獨查詢，是否需要建索引，我們看一下它的選擇性：
select count(distinct(title))/count(*) as selectivity from employees.titles;
+-------------+
| selectivity | +-------------+
| 0.0000 | +-------------+
mysql只對以下操作符才使用索引：<,<=,=,>,>=,between,in, 以及某些時候的like(不以萬用字元%或_開頭的情形)。
不要過度索引，只保持所需的索引。每個額外的索引都要占用額外的磁碟空間，並降低寫操作的效能。 在修改表的內容時，索引必須進行更新，有時可能需要重構，因此，索引越多，所花的時間越長。
高效使用索引的首要條件是知道什麼樣的查詢會使用到索引，這個問題和b+tree中的「最左字首原理」有關，下面通過例子說明最左字首原理。
這裡先說一下聯合索引的概念。在上文中，我們都是假設索引只引用了單個的列，實際上，mysql中的索引可以以一定順序引用多個列，這種索引叫做聯合索引，一般的，乙個聯合索引是乙個有序元組，其中各個元素均為資料表的一列，實際上要嚴格定義索引需要用到關係代數，但是這裡我不想討論太多關係代數的話題，因為那樣會顯得很枯燥，所以這裡就不再做嚴格定義。另外，單列索引可以看成聯合索引元素數為1的特例。
MySQL優化之 表策略和索引
本文試圖從資料表建立的策略 schema 和索引的角度描述優化選擇。資料越小越好。選擇滿足需求的最小資料型別。通過節省更多的磁碟空間，記憶體以及cache，使得你的資料庫更快。選擇簡單的型別。整形值相比於字元型的代價較小，因為字符集和校對規則的關係。比如說應該儲存日期和時間，而不是個字串 ip位址也...
MySQL索引優化策略分析
explain的用法 執行計畫 explain select from pms product where id 1 組合索引一定是最左匹配原則 如果你在表上建立了很多組合索引，索引檔案膨脹，修改 刪除 更新會比較慢expalin的作用 type 查詢的效果從上到下越來越差 優勢 提高查詢速度 表連...
mysql索引優化策略練手
create table t2 c1 char 1 not null default 0,c2 char 1 not null default 0,c3 char 1 not null default 0,c4 char 1 not null default 0,c5 char 1 not null...