高效能索引策略

• 高效能的索引策略（如何高效實用索引）

高效能的索引策略（如何高效實用索引）

1. 獨立的列：索引列不能是表示式的一部分，或者函式的引數。養成好習慣，始終將索引列單獨放在比較符的一側。

   示例：select * from xxtable where xxindex +1 = 10;
   xxindex是索引列，但是由於使用了表示式，導致索引失效；

2. 字首索引和索引選擇性：
   前提：索引很長的字串時，索引會變的很大也效率很低。
   此類情況解決辦法：第一種是使用模擬的雜湊索引（不懂不介紹），第二種就是字首索引。顧名思義，字首，是將較長字串從前向後擷取一部分，然後作為索引，減小了索引的空間從而提升索引效率。問題來了，擷取多少合適呢？此時提出了新名詞索引的選擇性
   ，書中也說明了，索引選擇性越高則查詢效率越高！那麼什麼是索引選擇性呢？其實方法很簡單，只是這個新名詞比較難理解，但實際的思路是很通俗的，就是字首選擇時儘可能可以代表唯一的一條記錄。
   索引選擇性是一個比值（比如5/10,索引選擇性就是0.5），被除數（5）表示的是不重複的記錄數，除數（10）表示的是總共的記錄數所以，可知唯一索引的索引選擇性是1，效能最好。

   通俗理解：如果要索引：abc、abd、adf時，如果字首索引選擇a(key(1))也就是a,則無法很好的區分三個索引，如果選擇ab(key(2))時，abc和abd無法區分，這是索引選擇性等於2/3，如果選擇key(3)時，就是唯一索引了。
   建立字首命令：ALTER TABLE pre_index_demo ADD KEY(city(2));

3. 多列索引：一個未來提高查詢效率的誤區，把where條件的列都加上索引，在多個列上建立單列索引，並不能提高MySQL的查詢效率。這樣做有時候並不能很好的提高效率，最好的效率也僅僅是一個一星索引。不如把忘掉where子句，集中精力優化索引的順序或者建立一個全覆蓋索引。（實踐5.6版本，好像已經被優化了，EXPLAIN時extra並沒有索引聯合或相交的提示）
4. 選擇合適的索引列順序：經驗法則，在不考慮排序和分組時，將索引選擇性（還記得怎麼計算嗎？）最高的列放在前面。
5. 聚簇索引：聚簇索引並不是一種單獨的索引型別，而是一種資料儲存方式。術語“聚簇”表示資料行和鍵值緊湊的儲存在一起，一個表只能有一個聚簇索引，因為資料只存一份。InnoDB的聚簇索引實際是在同一個結構中儲存了B-tree索引和資料行，葉子頁實際儲存了全部資料。InnoDB通過主鍵
   聚集資料，而B-Tree特點是順序存貯，故對於聚簇索引，索引的順序插入非常影響效能。一般建議主鍵是一個與資料無關的自動增長的數值，但是如果使用了UUID類似的作為主鍵，聚簇索引會產生大量的碎片和分頁，極其不建議。InnoDB的二級索引，儲存了主鍵的地址，故使用時需要回表，意思是先根據二級索引查詢到主鍵，然後根據主鍵查詢到資料行，需要查詢兩次，是一個不足支援。
6. 覆蓋索引：如果一個索引包含了所有查詢所需要的欄位的值，成為覆蓋索引。
7. 冗餘和重複索引：找到冗餘和重複索引，刪除即可。

索引的合理性，可使用響應時間來判斷，通過實際查詢來優化索引及SQL。