索引是存儲引擎用于快速找到記錄的一種數(shù)據(jù)結(jié)構(gòu), 它能提高查詢性能.

索引基礎(chǔ)

索引是在存儲引擎層實現(xiàn)的, MySQL支持以下幾種索引類型:

索引的類型

B-Tree索引

InnoDB使用了B+Tree, 特點是:

• 非葉子節(jié)點只存儲鍵值信息。
• 所有葉子節(jié)點之間都有一個鏈指針。
• 數(shù)據(jù)記錄都存放在葉子節(jié)點中。

截屏2020-02-24上午6.37.31.png

B+Tree的高度一般都在2~4層。mysql的InnoDB存儲引擎在設(shè)計時是將根節(jié)點常駐內(nèi)存的，也就是說查找某一鍵值的行記錄時最多只需要1~3次磁盤I/O操作.

數(shù)據(jù)庫中的B+Tree索引可以分為聚集索引（clustered index）和輔助索引（secondary index）。上面的B+Tree示例圖在數(shù)據(jù)庫中的實現(xiàn)即為聚集索引，聚集索引的B+Tree中的葉子節(jié)點存放的是整張表的行記錄數(shù)據(jù)。輔助索引與聚集索引的區(qū)別在于輔助索引的葉子節(jié)點并不包含行記錄的全部數(shù)據(jù)，而是存儲相應(yīng)行數(shù)據(jù)的聚集索引鍵，即主鍵。當通過輔助索引來查詢數(shù)據(jù)時，InnoDB存儲引擎會遍歷輔助索引找到主鍵，然后再通過主鍵在聚集索引中找到完整的行記錄數(shù)據(jù).

InnoDB存儲引擎中有頁（Page）的概念，頁是其磁盤管理的最小單位, InnoDB在把磁盤數(shù)據(jù)讀入到磁盤時會以頁為基本單位, 通過如下命令查看頁的大小:

mysql> show variables like 'innodb_page_size';

image.png

上表的索引對以下類型的查詢有效:

• 全值匹配全值匹配: 指的是和索引中的所有列進行匹配，例如前面提到的索引可用于查找姓名為Cuba Allen、出生于1960-01-01的人。
• 匹配最左前綴前面: 提到的索引可用于查找所有姓為Allen的人，即只使用索引的第一列。
• 匹配列前綴: 也可以只匹配某一列的值的開頭部分。例如前面提到的索引可用于查找所有以J開頭的姓的人。
• 匹配范圍值: 例如前面提到的索引可用于查找姓在Allen和Barrymore之間的人。這里也只使用了索引的第一列。
• 精確匹配某一列并范圍匹配另外一列: 前面提到的索引也可用于查找所有姓為Allen，并且名字是字母K開頭（比如Kim、Karl等）的人。
• 只訪問索引的查詢: B-Tree通常可以支持“只訪問索引的查詢”，即查詢只需要訪問索引，而無須訪問數(shù)據(jù)行。后面我們將單獨討論這種“覆蓋索引”的優(yōu)化。

B+Tree索引適用于全鍵值, 鍵值范圍或鍵前綴查找. 其中鍵前綴查找只適用于根據(jù)最左前綴的查找. 且因為索引樹中的節(jié)點是有序的, 索引除了按值查找外, 索引還可以用于查詢中的ORDER BY操作. 即滿足上面索引查詢的時候, 也可以滿足對應(yīng)的排序要求(不需再花費額外的內(nèi)存和時間).

哈希索引

哈希索引基于哈希表實現(xiàn)，只有精確匹配索引的所有列，索引才會生效。

哈希索引的限制：

1. 哈希索引只存儲哈希值和行指針，不存儲字段數(shù)據(jù)值，因此無法從索引中查詢數(shù)據(jù)
2. 哈希索引無法順序存儲，無法進行排序
3. 哈希索引不支持部分匹配，必須精確匹配所有索引列
4. 哈希索引不支持范圍查找
5. 哈希沖突會影響性能

可以創(chuàng)建自定義哈希索引(見書上的例子), 此時要避免沖突問題, 必須在where條件中帶入hash值和對應(yīng)列值, 只需要根據(jù)Hash值做快速的整數(shù)比較找到索引條目, 然后一一比較返回對應(yīng)的行.

空間數(shù)據(jù)索引(R-Tree)

用作地理數(shù)據(jù)存儲, MySQL支持的不完善, 比較好的是PostgresSQL的PostGIS.

全文索引

它查找的是文本中的關(guān)鍵詞, 而非直接比較索引中的值. 可以在相同的列上同時創(chuàng)建全文索引和基于值的B-Tree索引不會有沖突, 全文索引適用于MATCH AGAINST操作, 而非普通的WHERE條件操作. 第七章會討論更多全文索引的細節(jié).

索引的優(yōu)點

1. 大大減少服務(wù)器需要掃描的數(shù)據(jù)量
2. 可以幫助服務(wù)器避免排序和臨時表
3. 可以將隨機I/O變?yōu)轫樞騃//O

一星系統(tǒng):
索引將相關(guān)的記錄放到一起得一星.
二星系統(tǒng):
索引中的數(shù)據(jù)順序和查找中的排列順序一致得二星.
三星系統(tǒng):
索引中的列包含了查詢中需要的所有列得三星.

當然，索引也并不總是最好的工具。只有當索引幫助存儲引擎快速查找到記錄帶來的好處大于其帶來的額外工作時，索引才是有效的。非常小的表，大部分直接全表掃描更有效；中到大型的表，索引非常有效。特大型的表，則建立和使用索引的代價將隨之增長，需要一種技術(shù)可以區(qū)分出查詢需要的一組數(shù)據(jù)，如分區(qū)技術(shù)

高性能的索引策略

獨立的列

列不要進行參與計算:
where id+1=5應(yīng)該改成where id=4

前綴索引和索引選擇性

一種選擇索引的技巧是: 選擇足夠長的前綴保證較高的選擇性, 同時又不能太長(以便節(jié)約空間).

索引的選擇性是指: 不重復的索引值(也稱為基數(shù), cardinality)和數(shù)據(jù)表的總記錄數(shù)(#T)的比值, 范圍從1/#T到1之間. 索引的選擇性越高則查詢效率越高.

balabala, 若找到了合適的前綴長度, 則可用以下語句創(chuàng)建前綴索引:

mysql> ALTER TABLE sakila.city_demo ADD KEY (city(7));

查詢的時候where city='xxxxxxxxxx'自動會用到前綴索引
前綴索引優(yōu)點是: 使索引更小.
缺點是: MySQL無法使用前綴索引做ORDER BY和GROUP BY, 也無法使用前綴索引做覆蓋掃描.

多列索引

這里指多個單列索引, 不建議.

選擇合適的索引列順序

在一個多列B-Tree索引中, 索引列的順序意味著索引先按照最左邊進行排序, 其次是第二列, 等等.

經(jīng)驗法則: 將選擇性最高的列放在索引最前列. 但特殊情況有其他的標準.

聚簇索引

InnoDB的聚簇索引實際在同一個結(jié)構(gòu)中保存了B-Tree索引和數(shù)據(jù)行.
數(shù)據(jù)行存儲在葉子頁中, "聚簇"表示數(shù)據(jù)行和相鄰的鍵值緊湊地存儲在一起. 一個表只能有一個聚簇索引.

假設(shè)建表語句為:

mysql> create table T(
id int primary key, 
k int not null, 
name varchar(16),
index (k))engine=InnoDB;

image.png

主鍵索引的葉子節(jié)點存的是整行數(shù)據(jù)。在 InnoDB 里，主鍵索引也被稱為聚簇索引（clustered index）。

非主鍵索引的葉子節(jié)點內(nèi)容是主鍵的值。在 InnoDB 里，非主鍵索引也被稱為二級索引（secondary index）。

如果語句是 select * from T where ID=500，即主鍵查詢方式，則只需要搜索 ID 這棵 B+ 樹；如果語句是 select * from T where k=5，即普通索引查詢方式，則需要先搜索 k 索引樹，得到 ID 的值為 500，再到 ID 索引樹搜索一次。這個過程稱為回表。

索引維護

B+ 樹為了維護索引有序性，在插入新值的時候需要做必要的維護。
以上面這個圖為例，如果插入新的行 ID 值為 700，則只需要在 R5 的記錄后面插入一個新記錄。如果新插入的 ID 值為 400，就相對麻煩了，需要邏輯上挪動后面的數(shù)據(jù)，空出位置。而更糟的情況是，如果 R5 所在的數(shù)據(jù)頁已經(jīng)滿了，根據(jù) B+ 樹的算法，這時候需要申請一個新的數(shù)據(jù)頁，然后挪動部分數(shù)據(jù)過去。這個過程稱為頁分裂。
在這種情況下，性能自然會受影響。除了性能外，頁分裂操作還影響數(shù)據(jù)頁的利用率。原本放在一個頁的數(shù)據(jù)，現(xiàn)在分到兩個頁中，整體空間利用率降低大約 50%。當然有分裂就有合并。當相鄰兩個頁由于刪除了數(shù)據(jù)，利用率很低之后，會將數(shù)據(jù)頁做合并。合并的過程，可以認為是分裂過程的逆過程。

MyISAM的數(shù)據(jù)存儲

MyISAM的行數(shù)據(jù)按照數(shù)據(jù)插入的順序存儲在磁盤上, 索引也是B-Tree, 不過B-Tree的葉子節(jié)點存儲的是行號(行指針). MyISAM的主鍵和其他索引在結(jié)構(gòu)上沒有不同. 如下圖所示:

截屏2020-02-24下午11.41.53.png

要注意的是: InnoDB的二級索引的葉子節(jié)點存儲的不是行指針, 而是主鍵值, 這樣的好處是當行移動或數(shù)據(jù)頁分裂時, 無須更新二級索引中的主鍵值.

在InnoDB表中按主鍵順序插入行

盡量使用AUTO_INCREMENT自增列, 保證數(shù)據(jù)行是按順序?qū)懭?/strong>. 如果非順序插入, 會有以下幾個缺點: