標(biāo)題中的 「'對于非常小的表，大部分情況下簡單的全表掃描比建立索引更高效'」 ，其實(shí)是問題 「'索引的使用條件'」 的答案的一部分。完整答案是：

• 對于非常小的表、大部分情況下簡單的全表掃描比建立索引更高效
• 對于中到大型的表，索引就非常有效；

那么為什么對于非常小的表，大部分情況下簡單的全表掃描比建立索引更高效呢？理由如下：

MySQL的默認(rèn)存儲(chǔ)引擎是InnoDB，在InnoDB中索引是通過 B+ 樹實(shí)現(xiàn)的，MySQL的數(shù)據(jù)是存儲(chǔ)在聚簇索引（聚簇索引也叫主鍵索引、一級索引）的葉子節(jié)點(diǎn)上。

在輔助索引（包括唯一索引和非唯一索引）的的葉子節(jié)點(diǎn)上存儲(chǔ)著構(gòu)成索引的字段和主鍵。

如果查詢的字段不是索引的組成部分，就需要拿著從輔助索引中查到的主鍵值去聚簇索引中查詢數(shù)據(jù)，這個(gè)過程也叫做回表。

所以，如果一個(gè)表比較小，那么顯然直接遍歷表比走索引要快（因?yàn)樾枰乇恚?/p>

?

「注：首先，要注意這個(gè)答案隱含的條件是查詢的數(shù)據(jù)不是索引的構(gòu)成部分，否也不需要回表操作。其次，查詢條件也不是主鍵，否則可以直接從聚簇索引中拿到數(shù)據(jù)。」

?

這里有一個(gè)概念這里簡單總結(jié)一下：

「B+Tree 索引」

是大多數(shù) MySQL 存儲(chǔ)引擎的默認(rèn)索引類型。

因?yàn)椴辉傩枰M(jìn)行全表掃描，只需要對樹進(jìn)行搜索即可，所以查找速度快很多。

因?yàn)?B+ Tree 的有序性，所以除了用于查找，還可以用于排序和分組。

可以指定多個(gè)列作為索引列，多個(gè)索引列共同組成鍵。

適用于全鍵值、鍵值范圍和鍵前綴查找，其中鍵前綴查找只適用于最左前綴查找。如果不是按照索引列的順序進(jìn)行查找，則無法使用索引。

InnoDB 的 B+Tree 索引分為主索引和輔助索引。主索引的葉子節(jié)點(diǎn) data 域記錄著完整的數(shù)據(jù)記錄，這種索引方式被稱為聚簇索引。因?yàn)闊o法把數(shù)據(jù)行存放在兩個(gè)不同的地方，所以一個(gè)表只能有一個(gè)聚簇索引。

輔助索引的葉子節(jié)點(diǎn)的 data 域記錄著主鍵的值，因此在使用輔助索引進(jìn)行查找時(shí)，需要先查找到主鍵值，然后再到主索引中進(jìn)行查找。

「覆蓋索引」

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

具有以下優(yōu)點(diǎn)：

• 索引通常遠(yuǎn)小于數(shù)據(jù)行的大小，只讀取索引能大大減少數(shù)據(jù)訪問量。
• 一些存儲(chǔ)引擎（例如 MyISAM）在內(nèi)存中只緩存索引，而數(shù)據(jù)依賴于操作系統(tǒng)來緩存。因此，只訪問索引可以不使用系統(tǒng)調(diào)用（通常比較費(fèi)時(shí)）。
• 對于 InnoDB 引擎，若輔助索引能夠覆蓋查詢，則無需訪問主索引（無需回表）。

「索引的使用條件」

• 對于非常小的表、大部分情況下簡單的全表掃描比建立索引更高效；

• 對于中到大型的表，索引就非常有效；

• 但是對于特大型的表，建立和維護(hù)索引的代價(jià)將會(huì)隨之增長。這種情況下，需要用到一種技術(shù)可以直接區(qū)分出需要查詢的一組數(shù)據(jù)，而不是一條記錄一條記錄地匹配，例如可以使用分區(qū)技術(shù)。