什麼是InnoDB行儲存格式-mysql教程-PHP中文網

在早期的InnoDB版本中，由於檔案格式只有一種，因此不需要為此檔案格式命名。隨著InnoDB引擎的發展，開發了不相容早期版本的新檔案格式，用於支援新的功能。今天我們就來介紹一下InnoDB行儲存格式。

什麼是InnoDB行儲存格式

InnoDB儲存引擎支援四名的格式：REDUNDANT，COMPACT， DYNAMIC，和COMPRESSED。

InnoDB行格式概述

什麼是InnoDB行儲存格式

#REDUNDANT 行格式

REDUNDANT格式提供與舊版MySQL的相容性。
REDUNDANT行的格式是由兩個支援 InnoDB的檔案格式（Antelope和Barracuda）。
使用REDUNDANT行格式的表將可變長度列值（VARCHAR， VARBINARY和， BLOB和 TEXT類型）的前768個位元組儲存在B樹節點內的索引記錄中，其餘部分儲存在溢出頁面上。大於或等於768位元組的固定長度列被編碼為可變長度列，可以在頁外儲存。例如，CHAR(255)如果字元集的最大位元組長度大於3，則欄位可以超過768位元組utf8mb4。
如果列的值為768位元組或更少，則不使用溢出頁，並且可能導致I / O的一些節省，因為該值完全儲存在B樹節點中。這適用於相對較短的BLOB列值，但可能導致B樹節點填充資料而不是鍵值，從而降低其效率。具有許多BLOB列的表可能導致B樹節點變得太滿，並且包含的行太少，使得整個索引的效率低於行較短或列值儲存在頁外的情況。
REDUNDANT行格式有下列儲存特性：
每個索引記錄包含一個6位元組的標頭。標頭用於將連續記錄連結在一起，以及用於行級鎖定。
叢集索引中的記錄包含所有使用者定義列的欄位。此外，還有一個6位元組的事務ID欄位和一個7位元組的滾動指標欄位。
如果沒有為資料表定義主鍵，則每個叢集索引記錄也包含一個6位元組的行ID欄位。

每個輔助索引記錄包含為叢集索引鍵定義的所有主鍵列，這些列不在輔助索引中。

記錄包含指向記錄的每個欄位的指標。如果記錄中欄位的總長度小於128位元組，則指標為位元組; 否則，兩個位元組。指標數組稱為記錄目錄。指標指向的區域是記錄的資料部分。

在內部，固定長度的字元列，例如 CHAR(10)以固定長度格式儲存。尾隨空格不會從VARCHAR欄位中截斷。大於或等於768位元組的固定長度列被編碼為可變長度列，可以在頁外儲存。例如，CHAR(255)如果字元集的最大位元組長度大於3，則欄位可以超過768位元組 utf8mb4。

SQL NULL值在記錄目錄中保留一個或兩個位元組。 NULL如果儲存在可變長度列中，則SQL 值會在記錄的資料部分中保留零個位元組。對於固定長度的列，列的固定長度保留在記錄的資料部分中。為NULL 值保留固定空間允許將資料列從NULL非NULL值更新到非值，而不會導致索引頁碎片。

COMPACT 行格式

#######與REDUNDANT行格式相比，COMPACT行格式減少了大約20％的行儲存空間，REDUNDANT 代價是增加了某些作業的CPU使用。如果您的工作負載是受快取命中率和磁碟速度限制的典型工作負載，則COMPACT格式可能會更快。如果工作負載受CPU速度限制，則緊湊格式可能會變慢。 ######COMPACT行的格式是由兩個支援 InnoDB的檔案格式（Antelope和Barracuda）。 ######使用COMPACT行格式的表將可變長度列值（VARCHAR， VARBINARY和， BLOB和 TEXT類型）的前768個位元組儲存在B樹節點內的索引記錄中，其餘部分儲存在溢出頁面上。 ######大於或等於768位元組的固定長度列被編碼為可變長度列，可以在頁外儲存。例如，CHAR(255)如果字元集的最大位元組長度大於3，如果列是 utf8mb4 字元類型時可以超過768位元組。 ######如果列的值為768位元組或更少，則不使用溢出頁，並且可能導致 I/O 的一些節省，因為該值完全儲存在B樹節點中。這適用於相對較短的BLOB列值，但可能導致B樹節點填充資料而不是鍵值，從而降低其效率。具有許多BLOB列的表可能導致B樹節點變得太滿，並且包含的行太少，使得整個索引的效率低於行較短或列值儲存在頁外的情況。 ############COMPACT 行格式儲存特性#########

COMPACT行格式有下列儲存特性：

每個索引記錄包含一個5位元組的頭，可以在可變長度頭之前。標頭用於將連續記錄連結在一起，以及用於行級鎖定。
記錄頭的可變長度部分包含用於指示NULL列的位元向量。如果索引中的列數可以 NULL是N，則位元向量佔用位元組。（例如，如果可以有9到16列的任何位置，則位元向量使用兩個位元組。）不佔用此向量中的位元以外的空間的列。標題的可變長度部分還包含可變長度列的長度。每個長度需要一個或兩個字節，取決於列的最大長度。如果索引中的所有欄位都是CEILING(*N*/8)NULLNULLNOT NULL 且具有固定長度，則記錄頭沒有可變長度部分。
對於每個非NULL可變長度字段，記錄頭包含一個或兩個位元組的列長度。如果列的一部分儲存在溢出頁面的外部，或最大長度超過255個位元組且實際長度超過127個位元組，則只需要兩個位元組。對於外部儲存列，2位元組長度表示內部儲存部分的長度加上指向外部儲存部分的20位元組指標。內部部分為768字節，因此長度為768 20。20位元組指標儲存列的真實長度。
記錄頭後面是非NULL列的資料內容。
叢集索引中的記錄包含所有使用者定義列的欄位。此外，還有一個6位元組的事務ID欄位和一個7位元組的滾動指標欄位。
如果沒有為資料表定義主鍵，則每個叢集索引記錄也包含一個6位元組的行ID欄位。
每個輔助索引記錄包含為叢集索引鍵定義的所有主鍵列，這些列不在輔助索引中。如果任何主鍵列是可變長度，則每個輔助索引的記錄頭都有一個可變長度部分來記錄它們的長度，即使在固定長度列上定義了二級索引。
在內部，對於非變長字元集，固定長度字元列（例如以 CHAR(10)固定長度格式儲存）。尾隨空格不會從VARCHAR欄位中截斷。
在內部，對於可變長度字元集，例如 utf8mb3和utf8mb4， InnoDB嘗試透過修剪尾隨空格以位元組儲存。如果列值的位元組長度超過字節，則將尾隨空格調整為列值位元組長度的最小值。列的最大長度是最大字元位元組長度 × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)

N保留最少的位元組數。在許多情況下保留最小空間可以在不導致索引頁碎片的情況下完成列更新。相較之下，當使用行格式時，列佔用最大字元位元組長度× CHAR(*N*)NCHAR(*N*)NREDUNDANT

#大於或等於768位元組的固定長度列被編碼為可變長度字段，可以在頁外儲存。例如，CHAR(255)如果字元集的最大位元組長度大於3，如果列是 utf8mb4 字元類型時可以超過768位元組。

COMPACT 行格式儲存特性圖解

MySQL InnoDB COMPAT 行格式結構

什麼是InnoDB行儲存格式

MySQL InnoDB COMPAT 行格式結構頭訊息

什麼是InnoDB行儲存格式

MySQL InnoDB COMPAT 行格式結構頭資訊說明
| 名稱| 大小(bit) | 描述| | ———— | ——— | ———————————————————— | | 預留位| 1 | 未知| | 預留位| 1 | 未知| | delete_flag | 1 | 該行是否已刪除| | min_rec_flag | 1 | 為1，如果該記錄是預先被定義為最小的記錄| | n_owned | 4 | 該記錄擁有的記錄數| | heap_no | 13 | 索引堆中該記錄的排序記錄| | record_type | 3 | 記錄類型，000表示普通，001表示B 樹節點指針，010表示infimum，011表示supermum，1xx表示保留| | next_record | 16 | 頁中下一紀錄的相對位置

實際上， InnoDB 會每個資料加三個隱藏列，分別為

什麼是InnoDB行儲存格式

#DYNAMIC 行格式

DYNAMIC行格式提供相同的儲存特性的COMPACT行格式，但增加了對長可變長度列增強的儲存功能，並支援大型索引鍵的前綴。

Barracuda檔案格式支援DYNAMIC 行格式。

使用時建立表格 ROW_FORMAT=DYNAMIC，InnoDB 可以完全在頁外儲存長的可變長度欄位值（for VARCHAR， VARBINARY和， BLOB和 TEXT型別），叢集索引記錄只包含指向溢位頁的20字節指針。大於或等於768位元組的固定長度欄位被編碼為可變長度欄位。例如，CHAR(255)如果字元集的最大位元組長度大於3，如果列是 utf8mb4 字元類型時可以超過768位元組。

列是否儲存在頁外是否取決於頁面大小和行的總大小。當行太長時，選擇最長的列進行頁外存儲，直到叢集索引記錄適合B樹頁面。 TEXT且 BLOB是小於或等於40個位元組的欄位儲存在線路中。

DYNAMIC行格式保持儲存在它是否適合的索引節點整個行的效率（如做的 COMPACT和REDUNDANT 格式），但是DYNAMIC行格式避免填充B-樹節點具有大量長列的資料位元組的問題。此DYNAMIC行格式是基於這樣的思想，如果一個長的資料值的一部分被儲存關閉頁，它通常是最有效的儲存關閉頁整個值。對於DYNAMIC格式，較短的列可能保留在B樹節點中，從而最小化給定行所需的溢出頁數。

DYNAMIC行格式支援索引鍵的前綴可達3072個位元組。此功能由innodb_large_prefix變數控制，該變數預設為啟用。有關innodb_large_prefix更多信息，請參閱變數描述。

使用DYNAMIC行格式的表格可以儲存在系統表空間，每表檔案表空間和一般表空間。要DYNAMIC在系統表空間中儲存表，請停用 innodb_file_per_table和使用常規CREATE TABLE或ALTER TABLE語句，或將TABLESPACE [=] innodb_system表選項與CREATE TABLE或一起使用ALTER TABLE。在 innodb_file_per_table和 innodb_file_format變數不適用於一般的表格空間，也沒有使用時，它們是適用TABLESPACE [=] innodb_system 表選項儲存DYNAMIC在系統表空間表。

DYNAMIC 行格式儲存特性

DYNAMIC行格式是一個偏差 COMPACT行格式。

COMPRESSED 行格式

COMPRESSED行格式提供相同的儲存特性和功能的 DYNAMIC行格式，但增加了對資料表和索引數據壓縮的支援。

Barracuda檔案格式支援 COMPRESSED行格式。

COMPRESSED行格式使用類似的內部細節關閉頁儲存為DYNAMIC行格式，從資料表和索引資料的附加儲存和效能的考慮被壓縮，並使用較小的頁大小。使用COMPRESSED行格式，此KEY_BLOCK_SIZE選項控制在叢集索引中儲存的資料列資料量，以及溢出頁面上放置了多少。

COMPRESSED行格式支援索引鍵的前綴可達3072個位元組。此功能由innodb_large_prefix變數控制，該變數預設為啟用。

COMPRESSED可以在每個表的文件表空間或通用表空間中建立使用行格式的表。系統表空間不支援 COMPRESSED行格式。若要將COMPRESSED表格儲存在每個表格的檔案表空間中，innodb_file_per_table必須啟用該變量，且 innodb_file_format必須將其設為 Barracuda。在 innodb_file_per_table和 innodb_file_format變數不適用於一般的表格空間。一般表空間支援所有行格式，但需要注意的是，由於實體頁大小不同，壓縮和未壓縮表不能在同一個通用表空間中共存。有關更多信息，請參見第14.6.3.3節“常規表空間”。

COMPRESSED 行格式儲存特性

#COMPRESSED行格式是一個偏差 COMPACT行格式。只不過在處理行溢出資料時有點分歧，不會在記錄的真實資料處儲存字串的前768個字節，而是把所有的位元組都儲存到其他頁面中，只在記錄的真實數據處儲存其他頁面的位址。另外，Compressed 行格式會採用壓縮演算法對頁面進行壓縮。