學習筆記：InnoDB表和索引結構(二)

4、 自適應的雜湊索引

如果一個表幾乎完全快取在主記憶體中，在其上執行查詢最快的方法就是使用雜湊索引。InnoDB有一個自動機制，它監視對為一個表定義的索引的索引搜尋。如果InnoDB注意到查詢會從建立一個雜湊索引中獲益，它會自動地這麼做。

注意，雜湊索引總是基於表上已存在的B樹索引來建立。根據InnoDB對B樹索引觀察的搜尋方式，InnoDB會在為該B樹定義的任何長度的鍵的一個字首上建立雜湊索引。 雜湊索引可以是部分的：它不要求整個B樹索引被快取在緩衝池。InnoDB根據需要對被經常訪問的索引的那些頁面建立雜湊索引。

在某種意義上，InnoDB透過自適應的雜湊索引機制來調整自己，使其更加貼近主記憶體資料庫的架構。

[@more@]5、物理行結構
InnoDB表的物理行結構取決於表建立時指定的行格式。在MySQL 5.1中，InnoDB預設使用緊湊（COMPACT）格式，但為

了保留與舊版本MySQL的相容性，冗餘（REDUNDANT）格式也可用。檢視InnoDB表的行格式，可使用SHOW TABLE

STATUS命令。

緊湊的行格式大約可減少20%的儲存空間，但某些操作會增加CPU使用量。如果是一個典型的受限於快取記憶體命中率和

磁碟速度的工作負荷，使用緊湊格式可能會更快。如果是一種少見工作負荷情況，由於有限的CPU速度，緊湊格式可

能會比較慢。

使用冗餘行格式的InnoDB錶行具有以下特點：

• InnoDB中每個索引記錄包含一個6位元組的頭。這個頭被用來將連續的記錄連線在一起，並且也用在row-level鎖定中。
• 聚集索引裡的記錄包含所有的使用者定義列。此外，還有6個位元組的事務ID和一個7個位元組的回滾指標。
• 如果一個表沒有定義主鍵，每個聚集索引記錄還包含一個6位元組的RowID。
• 每個第二索引記錄包含聚集索引鍵定義的所有主鍵列。
• 一個記錄也包含一個指向該記錄每個列的指標，如果在一個記錄中列的總長度小於128位元組，該指標是一個位元組；否則就是2位元組。這些指標的陣列被稱為記錄目錄。這些指標指向的區域被稱為記錄的資料部分。
• 在內部，InnoDB以固定長度格式儲存固定長度的字元列，比如CHAR(10)。InnoDB不截斷VARCHAR列的尾隨空格。
• 一個SQL的NULL值在記錄目錄裡佔1到2位元組。例如，在一個可變長度列，如果存的是SQL的NULL值，則在記錄資料部分佔零位元組。在一個固定長度列，記錄的資料部分佔該列的固定長度。為NULL值保留固定空間的動機是之後該列從NULL值到非NULL值的更新可以就地完成，且不會導致索引頁的碎片。

使用緊湊行格式的InnoDB錶行具有以下特點：

• InnoDB中每個索引記錄包含一個5位元組的頭，在此之前是一個可變長度頭。這個頭被用來將連續的記錄連線在一起，並且也用在row-level鎖定中。
• 在記錄頭的可變長度部分包含一個用來標識NULL列的位向量。如果索引中可為NULL的列的數量為N，則該位向量佔用(N+7)/8個位元組。NULL列完全不佔用這個位向量以外的空間。在頭的可變長度部分也包含可變長列的長度。每個長度需要一個或兩個位元組，這取決於該列的最大長度。如果索引中的所有列都是NOT NULL的並且是固定長度的，記錄頭就沒有可變長度部分。
• 對於每一個非空的可變長欄位，記錄頭用一個或兩個位元組儲存列長度。兩個位元組只用在列的一部分資料外部儲存在溢位頁上或者列最大長度超過255個位元組並且實際長度超過127位元組的情況下。對於外部儲存的列，這兩個位元組長度表示內部儲存部分的長度加上20位元組的外部儲存指標。例如內部儲存部分是768位元組，這個長度就是768+20。20位元組長的指標儲存了列的真實長度。
• 記錄頭後緊跟著的是非空列的資料內容。
• 聚集索引裡的記錄包含所有的使用者定義列。此外，還有6個位元組的事務ID和一個7個位元組的回滾指標。
• 如果一個表沒有定義主鍵，每個聚集索引記錄還包含一個6位元組的RowID。
• 每個第二索引記錄也包含為聚集索引鍵定義的所有主鍵列。如果任何主鍵欄位是可變長的，則每一個第二索引的記錄頭必須有一個可變長部分來記錄這些可變長列的長度，即使第二索引是建立在固定長的列上。
• 在內部，InnoDB以固定長度格式儲存固定長度、固定寬度的字元列，如CHAR(10)。InnoDB不截斷VARCHAR列的尾隨空格。
• 在內部，InnoDB會將UTF-8的CHAR(N)的列儲存在N位元組裡，並截斷尾隨空格。（如果冗餘行格式，這樣的列會佔據3 ×N位元組。 ）在許多情況下，保留最低限度的空間N可以保持列在更新時不會造成索引碎片。