InnoDB行存儲格式是什么

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

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

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

InnoDB行格式概述

REDUNDANT 行格式

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

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

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

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

REDUNDANT 行格式存儲特性

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

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

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

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

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

• 記錄包含指向記錄的每個字段的指針。如果記錄中字段的總長度小于128字節(jié)，則指針是一個字節(jié); 否則，兩個字節(jié)。指針數(shù)組稱為記錄目錄。指針指向的區(qū)域是記錄的數(shù)據(jù)部分。

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

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

COMPACT 行格式

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

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

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

大于或等于768字節(jié)的固定長度列被編碼為可變長度列，可以在頁外存儲。例如，CHAR(255)如果字符集的最大字節(jié)長度大于3，如果列是 utf8mb4 字符類型時可以超過768字節(jié)。

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

COMPACT 行格式存儲特性

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

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

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

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

• 記錄頭后面是非NULL列的數(shù)據(jù)內(nèi)容。

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

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

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

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

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

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

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

COMPACT 行格式存儲特性圖解

MySQL InnoDB COMPAT 行格式結(jié)構(gòu)

MySQL InnoDB COMPAT 行格式結(jié)構(gòu)頭信息

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

實際上，InnoDB 會每條數(shù)據(jù)加三個隱藏列，分別為

DYNAMIC 行格式

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

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

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

列是否存儲在頁外是否取決于頁面大小和行的總大小。當行太長時，選擇最長的列進行頁外存儲，直到聚簇索引記錄適合B樹頁面。 TEXT并且 BLOB是小于或等于40個字節(jié)的列被存儲在線路。

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

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

使用DYNAMIC行格式的表可以存儲在系統(tǒng)表空間，每表文件表空間和一般表空間中。要DYNAMIC在系統(tǒng)表空間中存儲表，請禁用 innodb_file_per_table和使用常規(guī)CREATE TABLE或ALTER TABLE語句，或?qū)ABLESPACE [=] innodb_system表選項與CREATE TABLE或一起使用ALTER TABLE。在 innodb_file_per_table和 innodb_file_format變量不適用于一般的表空間，也沒有使用時，它們是適用TABLESPACE [=] innodb_system 表選項存儲DYNAMIC在系統(tǒng)表空間表。

DYNAMIC 行格式存儲特性

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

COMPRESSED 行格式

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

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

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

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

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

COMPRESSED 行格式存儲特性

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

感謝各位的閱讀，以上就是“InnoDB行存儲格式是什么”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對InnoDB行存儲格式是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！