初學MySQL 索引

索引維護

索引優化

總結索引的出現其實就是為了提高資料查詢的效率，就像書的目錄一樣。

常用的是雜湊表、有序陣列和搜尋樹來提高讀寫效率。

為了讓乙個查詢盡量少地讀磁碟，就必須讓查詢過程訪問盡量少的資料塊，不應該使用二叉樹，而是要使用"n叉"樹，「n」取決於資料塊的大小。

資料庫底層儲存的核心就是基於這些資料模型的，每碰到乙個新資料庫，需要先關注它的資料模型，才能從理論上分析這個資料庫的適用場景；

innodb使用了b+樹索引模型，所有的資料都是儲存在b+樹中的，每乙個索引在innodb中都對應一棵b+樹；

建立乙個主鍵列為id的表，表中有字段k,並且k上有索引，如下圖所示：

根據葉子節點的內容，索引型別分為主鍵索引和非主鍵索引；

兩種索引之間的區別？

非主鍵索引的查詢需要多掃瞄一棵樹，應用中盡量採用主鍵查詢。

b+樹為了維護索引有序性，在插入新值的時候，需要做必要的維護；

當所在的資料頁滿的時候，根據b+樹的演算法是需要申請乙個新的資料頁，然後挪動資料過去，這個過程被稱為頁**。

除了影響效能之外，頁**操作還會影響資料頁的利用率，原本放在一頁的資料，現在分到了兩頁中，整體的空間利用率降低約為50%；當相鄰兩個頁由於刪除了資料，利用了很低，就會將資料頁做合併，合併可以看作是**過程的逆過程；

自增主鍵是自增列上的定義的餓主鍵，語句定義為：

not null primary key auto_increment,插入新記錄的時候可以不指定id的值，系統會獲取當前id最大值加1作為下一條記錄的id值；

自增主鍵的插入資料模式，正好符合前面提到的遞增插入的場景，每次插入一條新紀錄都是追加操作，不需要挪動其它資料，也不會觸發葉子節點的**；

主鍵長度越小，普通索引的葉子節點就會越小，占用的空間也就越小。

對於典型的kv場景下，只有乙個索引，且該索引必須是唯一索引，適合將業務字段直接做主鍵。

//重建innodb表t的索引k
alter table t drop index k;
alter table t add index(k);
//重建主鍵索引
alter table t drop primary key;
alter table t add primary key(id);

如果要執行的語句是select id from where k between 3 and 5

id的值已經在k索引樹上，可以直接提供查詢結果，不需要回表；

由於覆蓋索引可以減少樹的搜尋次數，顯著提高查詢效能，覆蓋索引可以用來效能優化；

當索引包含所有需要查詢的字段的值。

具有以下優點：

b+樹的索引結構，可以利用索引的「最左字首」，來定位記錄，採用(name,age)這個聯合索引來進行分析：

第乙個字是「張」的人，sql語句是「where name like 『張%』」，查到第乙個記錄是id3,然後向後遍歷；

只要滿足最左字首，就可以利用索引來加速檢索，這個最左字首可以是聯合索引的最左n個字段，也可以是字串索引的最左m個字元；

在建立聯合索引的時候，如何安排索引內的字段排序？

以上圖中構建的市民表為例，需求：檢索出表中第乙個名字是張，且年齡為10的所有男孩，sql語句如下：

select *  from tuser where name like '張%' and age = 10 and is male = 1;

採用字首索引，找到了滿足第乙個條件的記錄id3,之後是判斷其它條件是否符合

在mysql5.6引入了索引下推優化(index condition pushdown),可以在索引遍歷過程中，對於索引中包含的字段先進行判斷，直接過濾掉不滿足的條件，減少回表次數，下圖是採用索引下推前後的過程圖。

乙個箭頭代表回表一次，兩圖之間的區別是，innodb在(name,age)索引內部就判斷了age是否等於10，對於不等於10的記錄，直接判斷並跳過；

在滿足語句需求的情況下，盡量少地訪問資源是資料庫設計的重要原則之一，在使用資料庫的時候，尤其是在設計表結構的時候，需要以減少資源消耗為目的。