索引策略

在《高性能的MYSQL》中對高性能的索引策略進行了描述，如今概括一下。

一，獨立的列。
指索引列不能是表達式的一部分，也不能是函數的參數。
Select actorI_id from actor where actor_id+1=5//不能使用索引。
策略：始終將索引列單獨放在比較符號的一側。

二，前綴索引。
前綴索引是指將字段列的前部分做爲索引存儲，它是一種平衡索引大小和效率的方法。
經過比較前綴的長度和索引的選擇性，來肯定前綴的長度（選擇性是指匹配的時候剩餘部分和所有的比值，條件多慮掉的越多選擇性越高）。這樣等到前綴長度的合適值，創建前綴索引。

三，多列索引
誤區：不是爲每一個列建立單獨的索引，或者按照錯誤的順序建立多列索引。
爲每一個列單獨的創建索引在mysql老的版本中甚至會採用全表掃描，新的版本中雖然會對索引進行合併，可是不少時候不是最優的選擇。在合併運算的時候會消耗更多的cpu和內存的資源。
而使用多列索引，多列索引的順序問題也是一個難題。在不須要考慮排序和分組的時候，咱們將選擇性最高的排在前列。

四，聚蔟索引
聚蔟索引是一種數據存儲的方式而不是一種單獨的索引類型。聚蔟表示相鄰的鍵值和數據行緊湊的存儲在一塊兒。
在mysql的InnoDB中是支持聚蔟索引，他的存儲方式是在B-Tree索引的葉子節點中直接存儲數據行。
在InnoDB中，默認會將表的主鍵當作聚蔟索引，若是沒有定義主鍵，則會選擇一個惟一的非空索引代替，可是若是不存在這樣的列，InnoDB會隱式的建立一個鍵當作聚蔟索引。
聚蔟索引的優勢：
1，相關的數據保存在一塊兒，IO更爲集中。
2，索引和數據記錄保存在同一個B-Tree中，因此比非聚蔟索引要快。
缺點：
1，插入的速度嚴重依賴於插入的速度，按照主鍵的順序最快。
2，聚蔟索引對於行比較稀疏的，聚蔟索引可能會致使全表掃描變慢。

Mysql的MyISSAM不支持聚蔟索引，因此數據的順序是按照插入的順序。主鍵索引和其餘索引沒有分別。
InnoDB中聚蔟索引的葉子節點直接存放數據，其餘非聚蔟索引的葉子節點指針指向主鍵，因此須要查詢2次。
對高併發工做負載中，按照主鍵順序插入可能形成明顯的爭用，主鍵上稱爲熱點，全部的插入都集中在這裏。
五，覆蓋索引 若是一個索引包含全部須要查詢的字段的值，那麼就稱之爲覆蓋索引。
覆蓋索引是分廠有用的工具，可以極大的提升性能。索引的條目一般是遠小於數據行大小的，因此若是隻是須要讀取索引，那麼在Mysql就會極大的減小數據的訪問量。
六 使用索引來作排序。
當索引的列順序和order by字句的順序徹底一致的時候Mysql可使用同一個索引及知足查找查找有知足排序。

七壓縮索引（前綴壓縮）
壓縮索引主要是使用前綴壓縮來減小索引的大小。從而讓更多的索引能夠放入內存中。
MyISAM壓縮索引的方式是，徹底保存索引塊中的第一個值，而後將其餘值和第一個值進行比較獲得相同的前綴的字節數和剩餘的不一樣的後綴。好比第一個值是abcd123，第二個值是abcdef4；那麼第二個值的存儲相似4,ef4;這樣的形式。
壓縮塊使用了更少的空間，可是每一個值的壓縮前綴都依賴前面的值，因此壓縮索引在查詢的時候不可以使用二分法查找只可以從頭開始查找。因此壓縮索引實際上是在cpu內存資源和磁盤之間作權衡。