一、MySQL中索引的語法

建立索引

在建立表的時候新增索引

CREATE TABLE mytable(  
    ID INT NOT NULL,   
    username VARCHAR(16) NOT NULL,  
    INDEX [indexName] (username(length))  
); 

在建立表以後新增索引

ALTER TABLE my_table ADD [UNIQUE] INDEX index_name(column_name);
或者
CREATE INDEX index_name ON my_table(column_name);

注意：

1、索引需要佔用磁碟空間，因此在建立索引時要考慮到磁碟空間是否足夠

2、建立索引時需要對錶加鎖，因此實際操作中需要在業務空閒期間進行

根據索引查詢

具體查詢：
SELECT * FROM table_name WHERE column_1=column_2;(為column_1建立了索引)

或者模糊查詢
SELECT * FROM table_name WHERE column_1 LIKE '%三'
SELECT * FROM table_name WHERE column_1 LIKE '三%'
SELECT * FROM table_name WHERE column_1 LIKE '%三%'

SELECT * FROM table_name WHERE column_1 LIKE '_好_'

如果要表示在字串中既有A又有B，那麼查詢語句為：
SELECT * FROM table_name WHERE column_1 LIKE '%A%' AND column_1 LIKE '%B%';

SELECT * FROM table_name WHERE column_1 LIKE '[張李王]三';  //表示column_1中有匹配張三、李三、王三的都可以
SELECT * FROM table_name WHERE column_1 LIKE '[^張李王]三';  //表示column_1中有匹配除了張三、李三、王三的其他三都可以

//在模糊查詢中，%表示任意0個或多個字元；_表示任意單個字元（有且僅有），通常用來限制字串長度;[]表示其中的某一個字元；[^]表示除了其中的字元的所有字元

或者在全文索引中模糊查詢
SELECT * FROM table_name WHERE MATCH(content) AGAINST('word1','word2',...);
 

刪除索引

DROP INDEX my_index ON tablename；
或者
ALTER TABLE table_name DROP INDEX index_name;

查看錶中的索引

SHOW INDEX FROM tablename

檢視查詢語句使用索引的情況

//explain 加查詢語句
explain SELECT * FROM table_name WHERE column_1='123';

二、索引的優缺點

優勢：可以快速檢索，減少I/O次數，加快檢索速度；根據索引分組和排序，可以加快分組和排序；

劣勢：索引本身也是表，因此會佔用儲存空間，一般來說，索引表佔用的空間的資料表的1.5倍；索引表的維護和建立需要時間成本，這個成本隨著資料量增大而增大；構建索引會降低資料表的修改操作（刪除，新增，修改）的效率，因為在修改資料表的同時還需要修改索引表；

三、索引的分類

常見的索引型別有：主鍵索引、唯一索引、普通索引、全文索引、組合索引

1、主鍵索引：即主索引，根據主鍵pk_clolum（length）建立索引，不允許重複，不允許空值；

ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col')；

2、唯一索引：用來建立索引的列的值必須是唯一的，允許空值

ALTER TABLE 'table_name' ADD UNIQUE index_name('col')；

3、普通索引：用表中的普通列構建的索引，沒有任何限制

ALTER TABLE 'table_name' ADD INDEX index_name('col')；

4、全文索引：用大文字物件的列構建的索引（下一部分會講解）

ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col')；

5、組合索引：用多個列組合構建的索引，這多個列中的值不允許有空值

ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3')；

*遵循“最左字首”原則，把最常用作為檢索或排序的列放在最左，依次遞減，組合索引相當於建立了col1,col1col2,col1col2col3三個索引，而col2或者col3是不能使用索引的。

*在使用組合索引的時候可能因為列名長度過長而導致索引的key太大，導致效率降低，在允許的情況下，可以只取col1和col2的前幾個字元作為索引

ALTER TABLE 'table_name' ADD INDEX index_name(col1(4),col2（3))；

表示使用col1的前4個字元和col2的前3個字元作為索引

四、索引的實現原理

MySQL支援諸多儲存引擎，而各種儲存引擎對索引的支援也各不相同，因此MySQL資料庫支援多種索引型別，如BTree索引，B+Tree索引，雜湊索引，全文索引等等，

1、雜湊索引：

只有memory（記憶體）儲存引擎支援雜湊索引，雜湊索引用索引列的值計算該值的hashCode，然後在hashCode相應的位置存執該值所在行資料的物理位置，因為使用雜湊演算法，因此訪問速度非常快，但是一個值只能對應一個hashCode，而且是雜湊的分佈方式，因此雜湊索引不支援範圍查詢和排序的功能。

2、全文索引：

FULLTEXT（全文）索引，僅可用於MyISAM和InnoDB，針對較大的資料，生成全文索引非常的消耗時間和空間。對於文字的大物件，或者較大的CHAR型別的資料，如果使用普通索引，那麼匹配文字前幾個字元還是可行的，但是想要匹配文字中間的幾個單詞，那麼就要使用LIKE %word%來匹配，這樣需要很長的時間來處理，響應時間會大大增加，這種情況，就可使用時FULLTEXT索引了，在生成FULLTEXT索引時，會為文字生成一份單詞的清單，在索引時及根據這個單詞的清單來索引。FULLTEXT可以在建立表的時候建立，也可以在需要的時候用ALTER或者CREATE INDEX來新增：

//建立表的時候新增FULLTEXT索引
CTREATE TABLE my_table(
    id INT(10) PRIMARY KEY,
    name VARCHAR(10) NOT NULL,
    my_text TEXT,
    FULLTEXT(my_text)
)ENGINE=MyISAM DEFAULT CHARSET=utf8;

//建立表以後，在需要的時候新增FULLTEXT索引
ALTER TABLE my_table ADD FULLTEXT INDEX ft_index(column_name);

全文索引的查詢也有自己特殊的語法，而不能使用LIKE %查詢字串%的模糊查詢語法

SELECT * FROM table_name MATCH(ft_index) AGAINST('查詢字串');

注意：

*對於較大的資料集，把資料新增到一個沒有FULLTEXT索引的表，然後新增FULLTEXT索引的速度比把資料新增到一個已經有FULLTEXT索引的錶快。

*5.6版本前的MySQL自帶的全文索引只能用於MyISAM儲存引擎，如果是其它資料引擎，那麼全文索引不會生效。5.6版本之後InnoDB儲存引擎開始支援全文索引

*在MySQL中，全文索引支隊英文有用，目前對中文還不支援。5.7版本之後通過使用ngram外掛開始支援中文。

*在MySQL中，如果檢索的字串太短則無法檢索得到預期的結果，檢索的字串長度至少為4位元組，此外，如果檢索的字元包括停止詞，那麼停止詞會被忽略。

3、BTree索引和B+Tree索引

• BTree索引

BTree是平衡搜尋多叉樹，設樹的度為2d（d>1），高度為h，那麼BTree要滿足以一下條件：

• 每個葉子結點的高度一樣，等於h；
• 每個非葉子結點由n-1個key和n個指標point組成，其中d<=n<=2d,key和point相互間隔，結點兩端一定是key；
• 葉子結點指標都為null；
• 非葉子結點的key都是[key,data]二元組，其中key表示作為索引的鍵，data為鍵值所在行的資料；

BTree的結構如下：

在BTree的機構下，就可以使用二分查詢的查詢方式，查詢複雜度為h*log(n)，一般來說樹的高度是很小的，一般為3左右，因此BTree是一個非常高效的查詢結構。

• B+Tree索引

B+Tree是BTree的一個變種，設d為樹的度數，h為樹的高度，B+Tree和BTree的不同主要在於：

• B+Tree中的非葉子結點不儲存資料，只儲存鍵值；
• B+Tree的葉子結點沒有指標，所有鍵值都會出現在葉子結點上，且key儲存的鍵值對應data資料的實體地址；
• B+Tree的每個非葉子節點由n個鍵值key和n個指標point組成；

B+Tree的結構如下：

B+Tree對比BTree的優點：

1、磁碟讀寫代價更低

一般來說B+Tree比BTree更適合實現外存的索引結構，因為儲存引擎的設計專家巧妙的利用了外存（磁碟）的儲存結構，即磁碟的最小儲存單位是扇區（sector），而作業系統的塊（block）通常是整數倍的sector，作業系統以頁（page）為單位管理記憶體，一頁（page）通常預設為4K，資料庫的頁通常設定為作業系統頁的整數倍，因此索引結構的節點被設計為一個頁的大小，然後利用外存的“預讀取”原則，每次讀取的時候，把整個節點的資料讀取到記憶體中，然後在記憶體中查詢，已知記憶體的讀取速度是外存讀取I/O速度的幾百倍，那麼提升查詢速度的關鍵就在於儘可能少的磁碟I/O，那麼可以知道，每個節點中的key個數越多，那麼樹的高度越小，需要I/O的次數越少，因此一般來說B+Tree比BTree更快，因為B+Tree的非葉節點中不儲存data，就可以儲存更多的key。

2、查詢速度更穩定

由於B+Tree非葉子節點不儲存資料（data），因此所有的資料都要查詢至葉子節點，而葉子節點的高度都是相同的，因此所有資料的查詢速度都是一樣的。

更多作業系統內容參考：

硬碟結構

扇區、塊、簇、頁的區別

作業系統層優化（進階，初學不用看）

• 帶順序索引的B+TREE

很多儲存引擎在B+Tree的基礎上進行了優化，添加了指向相鄰葉節點的指標，形成了帶有順序訪問指標的B+Tree，這樣做是為了提高區間查詢的效率，只要找到第一個值那麼就可以順序的查詢後面的值。

B+Tree的結構如下：

聚簇索引和非聚簇索引

分析了MySQL的索引結構的實現原理，然後我們來看看具體的儲存引擎怎麼實現索引結構的，MySQL中最常見的兩種儲存引擎分別是MyISAM和InnoDB，分別實現了非聚簇索引和聚簇索引。

聚簇索引的解釋是:聚簇索引的順序就是資料的物理儲存順序

非聚簇索引的解釋是:索引順序與資料物理排列順序無關

（這樣說起來並不好理解，讓人摸不著頭腦，清繼續看下文，並在插圖下方對上述兩句話有解釋）

首先要介紹幾個概念，在索引的分類中，我們可以按照索引的鍵是否為主鍵來分為“主索引”和“輔助索引”，使用主鍵鍵值建立的索引稱為“主索引”，其它的稱為“輔助索引”。因此主索引只能有一個，輔助索引可以有很多個。

MyISAM——非聚簇索引

• MyISAM儲存引擎採用的是非聚簇索引，非聚簇索引的主索引和輔助索引幾乎是一樣的，只是主索引不允許重複，不允許空值，他們的葉子結點的key都儲存指向鍵值對應的資料的實體地址。
• 非聚簇索引的資料表和索引表是分開儲存的。
• 非聚簇索引中的資料是根據資料的插入順序儲存。因此非聚簇索引更適合單個數據的查詢。插入順序不受鍵值影響。
• 只有在MyISAM中才能使用FULLTEXT索引。(mysql5.6以後innoDB也支援全文索引)

最開始我一直不懂既然非聚簇索引的主索引和輔助索引指向相同的內容，為什麼還要輔助索引這個東西呢，後來才明白索引不就是用來查詢的嗎，用在那些地方呢，不就是WHERE和ORDER BY 語句後面嗎，那麼如果查詢的條件不是主鍵怎麼辦呢，這個時候就需要輔助索引了。

InnoDB——聚簇索引

• 聚簇索引的主索引的葉子結點儲存的是鍵值對應的資料本身，輔助索引的葉子結點儲存的是鍵值對應的資料的主鍵鍵值。因此主鍵的值長度越小越好，型別越簡單越好。
• 聚簇索引的資料和主鍵索引儲存在一起。
• 聚簇索引的資料是根據主鍵的順序儲存。因此適合按主鍵索引的區間查詢，可以有更少的磁碟I/O，加快查詢速度。但是也是因為這個原因，聚簇索引的插入順序最好按照主鍵單調的順序插入，否則會頻繁的引起頁分裂，嚴重影響效能。
• 在InnoDB中，如果只需要查詢索引的列，就儘量不要加入其它的列，這樣會提高查詢效率。

使用主索引的時候，更適合使用聚簇索引，因為聚簇索引只需要查詢一次，而非聚簇索引在查到資料的地址後，還要進行一次I/O查詢資料。

*因為聚簇輔助索引儲存的是主鍵的鍵值，因此可以在資料行移動或者頁分裂的時候降低成本，因為這時不用維護輔助索引。但是由於主索引儲存的是資料本身，因此聚簇索引會佔用更多的空間。

*聚簇索引在插入新資料的時候比非聚簇索引慢很多，因為插入新資料時需要檢測主鍵是否重複，這需要遍歷主索引的所有葉節點，而非聚簇索引的葉節點儲存的是資料地址，佔用空間少，因此分佈集中，查詢的時候I/O更少，但聚簇索引的主索引中儲存的是資料本身，資料佔用空間大，分佈範圍更大，可能佔用好多的扇區，因此需要更多次I/O才能遍歷完畢。

下圖可以形象的說明聚簇索引和非聚簇索引的區別

從上圖中可以看到聚簇索引的輔助索引的葉子節點的data儲存的是主鍵的值，主索引的葉子節點的data儲存的是資料本身，也就是說資料和索引儲存在一起，並且索引查詢到的地方就是資料（data）本身，那麼索引的順序和資料本身的順序就是相同的；

而非聚簇索引的主索引和輔助索引的葉子節點的data都是儲存的資料的實體地址，也就是說索引和資料並不是儲存在一起的，資料的順序和索引的順序並沒有任何關係，也就是索引順序與資料物理排列順序無關。

此外MyISAM和innoDB的區別總結如下：

總結如下：

• InnoDB 支援事務，支援行級別鎖定，支援 B-tree、Full-text 等索引，不支援 Hash 索引；
• MyISAM 不支援事務，支援表級別鎖定，支援 B-tree、Full-text 等索引，不支援 Hash 索引；

此外，Memory 不支援事務，支援表級別鎖定，支援 B-tree、Hash 等索引，不支援 Full-text 索引；

五、索引的使用策略

什麼時候要使用索引？

• 主鍵自動建立唯一索引；
• 經常作為查詢條件在WHERE或者ORDER BY 語句中出現的列要建立索引；
• 作為排序的列要建立索引；
• 查詢中與其他表關聯的欄位，外來鍵關係建立索引
• 高併發條件下傾向組合索引；
• 用於聚合函式的列可以建立索引，例如使用了max(column_1)或者count(column_1)時的column_1就需要建立索引

什麼時候不要使用索引？

• 經常增刪改的列不要建立索引；
• 有大量重複的列不建立索引；
• 表記錄太少不要建立索引。只有當資料庫裡已經有了足夠多的測試資料時，它的效能測試結果才有實際參考價值。如果在測試資料庫裡只有幾百條資料記錄，它們往往在執行完第一條查詢命令之後就被全部載入到記憶體裡，這將使後續的查詢命令都執行得非常快--不管有沒有使用索引。只有當資料庫裡的記錄超過了1000條、資料總量也超過了MySQL伺服器上的記憶體總量時，資料庫的效能測試結果才有意義。

索引失效的情況：

• 在組合索引中不能有列的值為NULL，如果有，那麼這一列對組合索引就是無效的。
• 在一個SELECT語句中，索引只能使用一次，如果在WHERE中使用了，那麼在ORDER BY中就不要用了。
• LIKE操作中，'%aaa%'不會使用索引，也就是索引會失效，但是‘aaa%’可以使用索引。
• 在索引的列上使用表示式或者函式會使索引失效，例如：select * from users where YEAR(adddate)<2007，將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成：select * from users where adddate<’2007-01-01′。其它萬用字元同樣，也就是說，在查詢條件中使用正則表示式時，只有在搜尋模板的第一個字元不是萬用字元的情況下才能使用索引。
• 在查詢條件中使用不等於，包括<符號、>符號和！=會導致索引失效。特別的是如果對主鍵索引使用！=則不會使索引失效，如果對主鍵索引或者整數型別的索引使用<符號或者>符號不會使索引失效。（經erwkjrfhjwkdb同學提醒，不等於，包括<符號、>符號和！，如果佔總記錄的比例很小的話，也不會失效）
• 在查詢條件中使用IS NULL或者IS NOT NULL會導致索引失效。
• 字串不加單引號會導致索引失效。更準確的說是型別不一致會導致失效，比如欄位email是字串型別的，使用WHERE email=99999 則會導致失敗，應該改為WHERE email='99999'。
• 在查詢條件中使用OR連線多個條件會導致索引失效，除非OR連結的每個條件都加上索引，這時應該改為兩次查詢，然後用UNION ALL連線起來。
• 如果排序的欄位使用了索引，那麼select的欄位也要是索引欄位，否則索引失效。特別的是如果排序的是主鍵索引則select * 也不會導致索引失效。
• 儘量不要包括多列排序，如果一定要，最好為這佇列構建組合索引；

六、索引的優化

1、最左字首

索引的最左字首和和B+Tree中的“最左字首原理”有關，舉例來說就是如果設定了組合索引<col1,col2,col3>那麼以下3中情況可以使用索引：col1，<col1,col2>，<col1,col2,col3>，其它的列，比如<col2,col3>，<col1,col3>，col2，col3等等都是不能使用索引的。

根據最左字首原則，我們一般把排序分組頻率最高的列放在最左邊，以此類推。

2、帶索引的模糊查詢優化

在上面已經提到，使用LIKE進行模糊查詢的時候，'%aaa%'不會使用索引，也就是索引會失效。如果是這種情況，只能使用全文索引來進行優化（上文有講到）。

3、為檢索的條件構建全文索引，然後使用

SELECT * FROM tablename MATCH(index_colum) ANGAINST(‘word’);

4、使用短索引

對串列進行索引，如果可能應該指定一個字首長度。例如，如果有一個CHAR(255)的 列，如果在前10 個或20 個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。

原文連結：https://www.jianshu.com/p/c82148473235