InnoDB行存儲格式是什么

這篇文章主要講解了“InnoDB行存儲格式是什么”，文中的講解內容簡(jiǎn)單清晰，易于學(xué)習與理解，下面請大家跟著(zhù)小編的思路慢慢深入，一起來(lái)研究和學(xué)習“InnoDB行存儲格式是什么”吧！

在早期的InnoDB版本中，由于文件格式只有一種，因此不需要為此文件格式命名。隨著(zhù)InnoDB引擎的發(fā)展，開(kāi)發(fā)出了不兼容早期版本的新文件格式，用于支持新的功能。今天我們就來(lái)介紹一下InnoDB行存儲格式。

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

InnoDB行格式概述

REDUNDANT 行格式

REDUNDANT格式提供與舊版的兼容性。

REDUNDANT行的格式是由兩個(gè)支持 InnoDB的文件格式（Antelope和Barracuda）。

使用REDUNDANT行格式的表將可變長(cháng)度列值（VARCHAR， VARBINARY和， BLOB和 TEXT類(lèi)型）的前768個(gè)字節存儲在B樹(shù)節點(diǎn)內的索引記錄中，其余部分存儲在溢出頁(yè)面上。大于或等于768字節的固定長(cháng)度列被編碼為可變長(cháng)度列，可以在頁(yè)外存儲。例如，CHAR(255)如果字符集的最大字節長(cháng)度大于3，則列可以超過(guò)768字節utf8mb4。

如果列的值為768字節或更少，則不使用溢出頁(yè)，并且可能導致I / O的一些節省，因為該值完全存儲在B樹(shù)節點(diǎn)中。這適用于相對較短的BLOB列值，但可能導致B樹(shù)節點(diǎn)填充數據而不是鍵值，從而降低其效率。具有許多BLOB列的表可能導致B樹(shù)節點(diǎn)變得太滿(mǎn)，并且包含的行太少，使得整個(gè)索引的效率低于行較短或列值存儲在頁(yè)外的情況。

REDUNDANT 行格式存儲特性

REDUNDANT行格式有如下存儲特性：

• 每個(gè)索引記錄包含一個(gè)6字節的標頭。標頭用于將連續記錄鏈接在一起，以及用于行級鎖定。

• 聚簇索引中的記錄包含所有用戶(hù)定義列的字段。此外，還有一個(gè)6字節的事務(wù)ID字段和一個(gè)7字節的滾動(dòng)指針字段。

• 如果沒(méi)有為表定義主鍵，則每個(gè)聚簇索引記錄還包含一個(gè)6字節的行ID字段。

• 每個(gè)輔助索引記錄包含為聚簇索引鍵定義的所有主鍵列，這些列不在輔助索引中。

• 記錄包含指向記錄的每個(gè)字段的指針。如果記錄中字段的總長(cháng)度小于128字節，則指針是一個(gè)字節; 否則，兩個(gè)字節。指針數組稱(chēng)為記錄目錄。指針指向的區域是記錄的數據部分。

• 在內部，固定長(cháng)度的字符列，例如 CHAR(10)以固定長(cháng)度格式存儲。尾隨空格不會(huì )從VARCHAR列中截斷 。大于或等于768字節的固定長(cháng)度列被編碼為可變長(cháng)度列，可以在頁(yè)外存儲。例如，CHAR(255)如果字符集的最大字節長(cháng)度大于3，則列可以超過(guò)768字節 utf8mb4。

• SQL NULL值在記錄目錄中保留一個(gè)或兩個(gè)字節。NULL如果存儲在可變長(cháng)度列中，則SQL 值將在記錄的數據部分中保留零個(gè)字節。對于固定長(cháng)度的列，列的固定長(cháng)度保留在記錄的數據部分中。為NULL 值保留固定空間允許將列從NULL非NULL值更新 到非值，而不會(huì )導致索引頁(yè)碎片。

COMPACT 行格式

與REDUNDANT行格式相比，COMPACT行格式減少了大約20％的行存儲空間，REDUNDANT 代價(jià)是增加了某些操作的CPU使用。如果您的工作負載是受緩存命中率和磁盤(pán)速度限制的典型工作負載，則COMPACT格式可能會(huì )更快。如果工作負載受CPU速度限制，則緊湊格式可能會(huì )變慢。

COMPACT行的格式是由兩個(gè)支持 InnoDB的文件格式（Antelope和Barracuda）。

使用COMPACT行格式的表將可變長(cháng)度列值（VARCHAR， VARBINARY和， BLOB和 TEXT類(lèi)型）的前768個(gè)字節存儲在B樹(shù)節點(diǎn)內的索引記錄中，其余部分存儲在溢出頁(yè)面上。

大于或等于768字節的固定長(cháng)度列被編碼為可變長(cháng)度列，可以在頁(yè)外存儲。例如，CHAR(255)如果字符集的最大字節長(cháng)度大于3，如果列是 utf8mb4 字符類(lèi)型時(shí)可以超過(guò)768字節。

如果列的值為768字節或更少，則不使用溢出頁(yè)，并且可能導致 I/O 的一些節省，因為該值完全存儲在B樹(shù)節點(diǎn)中。這適用于相對較短的BLOB列值，但可能導致B樹(shù)節點(diǎn)填充數據而不是鍵值，從而降低其效率。具有許多BLOB列的表可能導致B樹(shù)節點(diǎn)變得太滿(mǎn)，并且包含的行太少，使得整個(gè)索引的效率低于行較短或列值存儲在頁(yè)外的情況。

COMPACT 行格式存儲特性

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

• 每個(gè)索引記錄包含一個(gè)5字節的頭，可以在可變長(cháng)度頭之前。標頭用于將連續記錄鏈接在一起，以及用于行級鎖定。

• 記錄頭的可變長(cháng)度部分包含用于指示NULL列的位向量。如果索引中的列數可以 NULL是N，則位向量占用 字節。（例如，如果可以有9到16列的任何位置，則位向量使用兩個(gè)字節。）不占用此向量中的位以外的空間的列。標題的可變長(cháng)度部分還包含可變長(cháng)度列的長(cháng)度。每個(gè)長(cháng)度需要一個(gè)或兩個(gè)字節，具體取決于列的最大長(cháng)度。如果索引中的所有列都是CEILING(*N*/8)NULLNULLNOT NULL 并且具有固定長(cháng)度，記錄頭沒(méi)有可變長(cháng)度部分。

• 對于每個(gè)非NULL可變長(cháng)度字段，記錄頭包含一個(gè)或兩個(gè)字節的列長(cháng)度。如果列的一部分存儲在溢出頁(yè)面的外部，或者最大長(cháng)度超過(guò)255個(gè)字節且實(shí)際長(cháng)度超過(guò)127個(gè)字節，則只需要兩個(gè)字節。對于外部存儲列，2字節長(cháng)度表示內部存儲部分的長(cháng)度加上指向外部存儲部分的20字節指針。內部部分為768字節，因此長(cháng)度為768 + 20。20字節指針存儲列的真實(shí)長(cháng)度。

• 記錄頭后面是非NULL列的數據內容。

• 聚簇索引中的記錄包含所有用戶(hù)定義列的字段。此外，還有一個(gè)6字節的事務(wù)ID字段和一個(gè)7字節的滾動(dòng)指針字段。

• 如果沒(méi)有為表定義主鍵，則每個(gè)聚簇索引記錄還包含一個(gè)6字節的行ID字段。

• 每個(gè)輔助索引記錄包含為聚簇索引鍵定義的所有主鍵列，這些列不在輔助索引中。如果任何主鍵列是可變長(cháng)度，則每個(gè)輔助索引的記錄頭都有一個(gè)可變長(cháng)度部分來(lái)記錄它們的長(cháng)度，即使在固定長(cháng)度列上定義了二級索引。

• 在內部，對于非變長(cháng)字符集，固定長(cháng)度字符列（例如以 CHAR(10)固定長(cháng)度格式存儲）。尾隨空格不會(huì )從VARCHAR列中截斷 。

• 在內部，對于可變長(cháng)度字符集，例如 utf8mb3和utf8mb4， InnoDB嘗試通過(guò)修剪尾隨空格以字節存儲 。如果列值的字節長(cháng)度 超過(guò)字節，則將尾隨空格調整為列值字節長(cháng)度的最小值。 列的最大長(cháng)度 是最大字符字節長(cháng)度 × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)

N保留 最少的字節數 。在許多情況下保留最小空間可以在不導致索引頁(yè)碎片的情況下完成列更新。相比之下，當使用行格式時(shí)，列占用最大字符字節長(cháng)度 × CHAR(*N*)NCHAR(*N*)NREDUNDANT

大于或等于768字節的固定長(cháng)度列被編碼為可變長(cháng)度字段，可以在頁(yè)外存儲。例如，CHAR(255)如果字符集的最大字節長(cháng)度大于3，如果列是 utf8mb4 字符類(lèi)型時(shí)可以超過(guò)768字節。

COMPACT 行格式存儲特性圖解

MySQL InnoDB COMPAT 行格式結構

MySQL InnoDB COMPAT 行格式結構頭信息

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

實(shí)際上，InnoDB 會(huì )每條數據加三個(gè)隱藏列，分別為

DYNAMIC 行格式

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

Barracuda文件格式支持DYNAMIC 行格式。

使用時(shí)創(chuàng )建表 ROW_FORMAT=DYNAMIC，InnoDB 可以完全在頁(yè)外存儲長(cháng)的可變長(cháng)度列值（for VARCHAR， VARBINARY和， BLOB和 TEXT類(lèi)型），聚簇索引記錄只包含指向溢出頁(yè)的20字節指針。大于或等于768字節的固定長(cháng)度字段被編碼為可變長(cháng)度字段。例如，CHAR(255)如果字符集的最大字節長(cháng)度大于3，如果列是 utf8mb4 字符類(lèi)型時(shí)可以超過(guò)768字節。

列是否存儲在頁(yè)外是否取決于頁(yè)面大小和行的總大小。當行太長(cháng)時(shí)，選擇最長(cháng)的列進(jìn)行頁(yè)外存儲，直到聚簇索引記錄適合B樹(shù)頁(yè)面。 TEXT并且 BLOB是小于或等于40個(gè)字節的列被存儲在線(xiàn)路。

DYNAMIC行格式保持存儲在它是否適合的索引節點(diǎn)整個(gè)行的效率（如做的 COMPACT和REDUNDANT 格式），但是DYNAMIC行格式避免填充B-樹(shù)節點(diǎn)具有大量長(cháng)列的數據字節的問(wèn)題。該DYNAMIC行格式是基于這樣的思想，如果一個(gè)長(cháng)的數據值的一部分被存儲關(guān)閉頁(yè)，它通常是最有效的存儲關(guān)閉頁(yè)整個(gè)值。對于DYNAMIC格式，較短的列可能保留在B樹(shù)節點(diǎn)中，從而最小化給定行所需的溢出頁(yè)數。

DYNAMIC行格式支持索引鍵的前綴可達3072個(gè)字節。此功能由innodb_large_prefix變量控制，該 變量默認啟用。有關(guān)innodb_large_prefix更多信息，請參閱 變量描述。

使用DYNAMIC行格式的表可以存儲在系統表空間，每表文件表空間和一般表空間中。要DYNAMIC在系統表空間中存儲表，請禁用 innodb_file_per_table和使用常規CREATE TABLE或ALTER TABLE語(yǔ)句，或將TABLESPACE [=] innodb_system表選項與CREATE TABLE或一起使用ALTER TABLE。在 innodb_file_per_table和 innodb_file_format變量不適用于一般的表空間，也沒(méi)有使用時(shí)，它們是適用TABLESPACE [=] innodb_system 表選項存儲DYNAMIC在系統表空間表。

DYNAMIC 行格式存儲特性

DYNAMIC行格式是一個(gè)偏差 COMPACT行格式。

COMPRESSED 行格式

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

Barracuda文件格式支持 COMPRESSED行格式。

COMPRESSED行格式使用類(lèi)似的內部細節關(guān)閉頁(yè)存儲為DYNAMIC行格式，從表和索引數據的附加存儲和性能的考慮被壓縮，并使用較小的頁(yè)大小。使用COMPRESSED行格式，該KEY_BLOCK_SIZE選項控制在聚簇索引中存儲的列數據量，以及溢出頁(yè)面上放置了多少。

COMPRESSED行格式支持索引鍵的前綴可達3072個(gè)字節。此功能由innodb_large_prefix變量控制，該 變量默認啟用。

COMPRESSED可以在每個(gè)表的文件表空間或通用表空間中創(chuàng )建 使用行格式的表。系統表空間不支持 COMPRESSED行格式。要將COMPRESSED表存儲 在每個(gè)表的文件表空間中，innodb_file_per_table必須啟用該 變量，并且 innodb_file_format必須將其設置為 Barracuda。在 innodb_file_per_table和 innodb_file_format變量不適用于一般的表空間。一般表空間支持所有行格式，但需要注意的是，由于物理頁(yè)面大小不同，壓縮和未壓縮表不能在同一個(gè)通用表空間中共存。有關(guān)更多信息，請參見(jiàn) 第14.6.3.3節“常規表空間”。

COMPRESSED 行格式存儲特性

COMPRESSED行格式是一個(gè)偏差 COMPACT行格式。只不過(guò)在處理行溢出數據時(shí)有點(diǎn)兒分歧，不會(huì )在記錄的真實(shí)數據處存儲字符串的前768個(gè)字節，而是把所有的字節都存儲到其他頁(yè)面中，只在記錄的真實(shí)數據處存儲其他頁(yè)面的地址。另外，Compressed 行格式會(huì )采用壓縮算法對頁(yè)面進(jìn)行壓縮。