mysql的索引——innodb索引（1）聚簇索引和次級索引

官方文檔翻譯：mysql的索引——innodb索引（1）聚簇索引和次級索引

14.2.9.1 Clustered and Secondary Indexes

聚簇索引和次級索引

Every InnoDB table has a special index called the clustered index where the data for the rows is stored. Typically, the clustered index is synonymous with the primary key. To get the best performance from queries, inserts, and other database operations, you must understand how InnoDB uses the clustered index to optimize the most common lookup and DML operations for each table.

每張Innodb引擎表都有一個特殊的索引，聚簇索引，它保存着每行數據。通常狀況，聚簇索引就是主鍵索引。爲了獲得更高效的查詢，插入，或者其餘的數據庫操做，你必須理解innodb引擎如何使用聚簇索引優化大多數查詢和dml操做。

• If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.

• If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULLcolumns as the primary key and InnoDB uses it as the clustered index.

• If the table has no PRIMARY KEY or suitable UNIQUE index, InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.

• 若是你爲表定義了一個主鍵，innodb就使用它做爲聚簇索引。
• 若是你沒有定義主鍵，mysql選擇非空類型的惟一索引來做爲做爲主鍵，而且innodb會用它做爲聚簇索引。
• 若是表中既沒有主鍵，又沒有合適的惟一索引，innodb內部生成一個隱式聚簇索引，建在由rowid組成的虛擬列上。在這張表中，innodb爲每行數據指定一個rowid，數據行根據ID來排序。這些row id是由一些佔6字節空間的自增加列組成。當有新數據插入的時候，row id增加，這樣，保證row id就是按照數據的物理寫入順序來組織行。

How the Clustered Index Speeds Up Queries

聚簇索引提升了查詢效率？

Accessing a row through the clustered index is fast because the row data is on the same page where the index search leads. If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations that store row data using a different page from the index record. (For example, MyISAMuses one file for data rows and another for index records.)

經過聚簇索引來尋找一行數據是很是快的，這是由於行數據和index保存在由index開頭的同一個page上。若是表特別大，聚簇索引的這種構造就能節省磁盤I/O資源（索引和數據在不一樣頁上時，根據索引來尋找數據存儲頁消耗的IO），好比myisam引擎，把索引和數據頁分開存放；

How Secondary Indexes Relate to the Clustered Index

次級索引和聚簇索引之間是如何關聯的？

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.

除了聚簇索引以外的其餘索引類型都屬於次級索引。在Innodb中，次級索引的每行數據都包含這條數據的主鍵列，主鍵列就像是爲次級索引本身制定的列；彙集索引中，innodb經過主鍵值來查找數據行。

If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

若是主鍵過長，次級索引就須要更大的空間，所以，使用短的主鍵列是很是有用的。

 

總結：

一、啥是聚簇索引？啥是主鍵索引？啥叫輔助索引（二級索引）？

聚簇索引：索引指針直接指向數據頁的索引，聚簇索引對數據物理頁按索引鍵值進行物理組織排序；

主鍵索引：建在主鍵上的索引；innodb中，聚簇索引在有主鍵的狀況下，默認指定主鍵爲聚簇索引,所以,innodb中，主鍵索引通常都是聚簇索引。

二級索引：除了聚簇索引的，都稱爲2級索引；innodb中，二級索引查找數據行，須要先找到對應的主鍵，而後根據主鍵查找對應的行值。

 

二、聚簇索引的選擇？

innodb中，聚簇索引是mysql本身來決定的。選擇的順序是：

（1）定義了主鍵，就選擇主鍵；

（2）沒有主鍵，選擇第一個非空的惟一索引；

（3）二者都沒有，innodb本身生成一個佔6byte的自增加列。而後以它做爲聚簇索引列

不少參考上提到：不一樣表的自增加列存放在同一個表中，由mysql本身管理。查詢時，須要先在這張表中找到自增加列，而後再去找對應的數據；這樣一來，由於全部的自建ID存放在這張表中，所以，這張表就變成了查詢的瓶頸，致使innodb自建主鍵的效率比指定主鍵差。

尚未作過驗證。

三、次級索引隱式包含主鍵的列。

四、在聚簇索引的每一個葉節點上，存放以index鍵開始的index+數據行，省去了根據索引查找數據頁的I/O;