1 行記錄格式的分類和介紹
在早期的InnoDB版本中，由於文件格式只有一種，因此不需要爲此文件格式命名。隨着InnoDB引擎的發展，開發出了不兼容早期版本的新文件格式，用於支持新的功能。爲了在升級和降級情況下幫助管理系統的兼容性，以及運行不同的MySQL版本，InnoDB開始使用命名的文件格式。官網關於InnoDB 行格式介紹
1. Antelope: 先前未命名的，原始的InnoDB文件格式。它支持兩種行格式：COMPACT 和 REDUNDANT。MySQL5.6的默認文件格式。可以與早期的版本保持最大的兼容性。不支持 Barracuda 文件格式。
2. Barracuda: 新的文件格式。它支持InnoDB的所有行格式，包括新的行格式：COMPRESSED 和 DYNAMIC。與這兩個新的行格式相關的功能包括：InnoDB表的壓縮，長列數據的頁外存儲和索引建前綴最大長度爲3072字節。
在 msyql 5.7.9 及以後版本，默認行格式由innodb_default_row_format變量決定，它的默認值是DYNAMIC，也可以在 create table 的時候指定ROW_FORMAT=DYNAMIC。用戶可以通過命令 SHOW TABLE STATUS LIKE'table_name' 來查看當前表使用的行格式，其中 row_format 列表示當前所使用的行記錄結構類型。
PS：如果要修改現有表的行模式爲compressed或dynamic，必須先將文件格式設置成Barracuda：set global innodb_file_format=Barracuda;，再用ALTER TABLE tablename ROW_FORMAT=COMPRESSED;去修改才能生效。
mysql> show variables like "innodb_file_format";
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| innodb_file_format | Barracuda |
+--------------------+-----------+
1 row in set (0.00 sec)
mysql> show table status like "test%"\G
*************************** 1. row ***************************
Name: test
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 4
Avg_row_length: 20
Data_length: 80
Max_data_length: 281474976710655
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2018-08-07 13:07:59
Update_time: 2018-08-07 13:08:01
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options: row_format=DYNAMIC
Comment:
2 InnoDB行存儲
一個表的行格式決定了它的行是物理存儲,進而會影響查詢和DML操作的性能。隨着越來越多行適合單個磁盤頁面,查詢和索引查找可以更快,更少的緩存內存緩衝池中是必需的,和更少的I / O要求寫出更新的值。
每個表中的數據分爲頁面。每個表的頁面被安排在一個叫做b -樹索引樹的數據結構。表數據和二級索引都使用這種類型的結構。代表整個的b -樹索引表被稱爲聚集索引,這是組織根據主鍵列。節點的聚集索引數據結構包含所有列的值的行。二級索引結構的節點包含索引列的值和主鍵列。
可變長度列是一個例外,列值存儲在b -樹索引節點。可變長度列b - tree頁面太長,以適應分別存儲在磁盤頁稱爲溢出頁分配。這樣的列被稱爲線下列。線下列的值存儲在單鏈表溢出頁,每個這樣的列都有自己的一個或多個溢出列表頁面。根據列的長度,或者一個前綴的可變長度列值存儲在b -樹,以避免浪費存儲和讀取一個單獨的頁面。
InnoDB存儲引擎支持四行格式：REDUNDANT, COMPACT, DYNAMIC和 COMPRESSED
行記錄格式表
| Row Format | Compact Storage Characteristics | Enhanced Variable-Length Column Storage | Large Index Key Prefix Support | Compression Support | Supported Tablespace Types | Required File Format |
|---|---|---|---|---|---|---|
REDUNDANT |
No | No | No | No | system, file-per-table, general | Antelope or Barracuda |
COMPACT |
Yes | No | No | No | system, file-per-table, general | Antelope or Barracuda |
DYNAMIC |
Yes | Yes | Yes | No | system, file-per-table, general | Barracuda |
COMPRESSED |
Yes | Yes | Yes | Yes | file-per-table, general | Barracuda |
1.REDUNDANT
（1）B-tree存儲變長列（VARCHAR, VARBINARY, BLOB, TEXT）的前768字節，剩下的部分存儲在溢出頁中。
（2）固定長度列，超過768字節的視爲變長列。
特點：
（1）每個索引記錄包括6字節頭，頭部用於將連續的記錄連接在一起，並用於鎖定行。
（2）聚集索引中的記錄，包括用戶定義的全部列。另外，有一個6字節的事務ID和7字節的滾動指針。
（3）如果表中沒有定義一個主鍵，記錄也會包含一個6字節的行ID。
（4）每個二級索引記錄包含主鍵列。
（5）每條記錄的字段對應一個指針，如果字段的長度少於128字節，指針則是一個字節，否則就是兩個字節。指針數組稱爲記錄目錄。指針指向的區域爲記錄的數據部分。
（6）固定長度的列，CHAR(10)，以固定長度格式存儲。VARCHAR的結尾空格不會截斷。
（7）固定長度列大於768字節的，以變長列編碼。
（8）SQl-null值存儲一個或者兩個字節在記錄目錄中，若爲變長數據區域無值。若爲固定長度，數據區域存儲固定長度，值爲null。爲NULL保留固定長度允許列由null更新爲non-null，避免索引頁碎片。
2.COMPACT
compact格式比redundant存儲空間減少20%。如果受限於cache命中和磁盤速度，compact格式會快一些，若受限於CPU速度，compact格式會慢一些。
compact格式存儲變長列的前768字節於B-tree節點中，剩餘部分存儲在溢出頁中。固定長度大於768字節的以變長列方式處理。
特點：
（1）每個索引記錄包含5個字節頭部，頭部之前可能會有一個變長的頭。頭部用於鏈接連續的記錄以及行級鎖定。
（2）變長記錄的頭部包含bit向量標誌NULL列。若列中可以爲NULL的列數量爲N，bit向量佔CEILING(N/8)字節。頭部變長部分也包含變長列的長度，視列最大長度而定，佔1個或2字節。若全部列不能爲null且有固定長度，記錄頭部則無變長部分。
（3）對於每個non-null變長字段，記錄頭部包含一個字節或兩個字節長度，存儲列長度。若列存儲於溢出頁或者最大列長度超過255字節，而且實際長度超過127字節時需要兩個字節。對於外部存儲的列，2字節長度表示內部存儲列部分的長度加上指向外部存儲的20字節指針。內部存儲部分768字節，所以長度爲768+20。20字節指針存儲列的真實長度。
（4）聚集索引中的記錄包括全部用戶定義的列。另外，還有一個6字節的事務ID和7字節滾動指針。
（5）如果表內沒有定義主鍵，聚集索引記錄則會包含一個6字節的行ID。
（6）每個二級索引記錄包含所有主鍵列。如果有變長的主鍵列，二級索引記錄的頭部有一個變長部分記錄它們的長度，儘管二級索引定義在固定長度列上。
（7）內部，固定長度字符列以固定長度存儲。對於VARCAHR尾部空格部位截斷；
（8）對於變長字符，InnoDB嘗試用N字節存儲Char(N)，包括去除尾部空格；若字符字節數超過N,最小字符長度爲結尾空格剔除後的值，最大爲字符最大字節長度*N。
3.DYNAMIC
基於compact格式，提高存儲容量，支持大索引（large index）3072字節，由innodb_large_prefix參數控制。
(1) 行格式爲dynamic時，變長列爲完全頁外存儲，聚集索引記錄包含一個20字節的指針指向溢出頁。固定長度列，超過768字節時，以變長列方式存儲。
(2) 列是否存儲在頁外時，依賴頁大小和行總大小。
當一行太長時，將選擇最長的列作爲頁外存儲，直到聚集索引記錄適合於B-tree頁面。TEXT或者BLOB列小於40字節的存儲一行。
(3) 可採用系統表空間，獨立表空間，普通表空間。
4.COMPRESSED
基於dynamic格式，支持表和索引數據壓縮。compressed行格式採用dynamic相同的頁外存儲細節，和額外的需要壓縮的表和索引數據存儲，更小的頁大小。KEY_BLOCK_SIZE參數控制由多少列數據存儲在聚集索引，多少存儲在溢出頁。
3 行格式詳解
3.1 Compact 和 Redundant
（一）Compact
Compact行記錄是在MySQL5.0中引入的，爲了高效的存儲數據，簡單的說，就是爲了讓一個頁（Page）存放的行數據越多，這樣性能就越高。行記錄格式如下：
1. 變長字段長度列表：變長字段長度最大不超過2字節（MySQL數據庫varcahr類型的最大長度限制爲65535）
2. NULL標識位：該位指示了該行數據中是否有NULL值，有則用1。
3. 記錄頭信息：固定佔用5字節（40位）
4. 列N數據：實際存儲每列的數據，NULL不佔該部分任何空間，即NULL佔有NULL標誌位，實際存儲不佔任何空間。
PS：每一行數據除了用戶定義的例外，還有兩個隱藏列，事物ID列和回滾指針列，分別位6字節和7字節的大小，若InnoDB表沒有定義主鍵，每行還未增加一個6字節的rowid列。
（二）Redundant
MySQL5.0之前的行記錄格式：
1. 字段偏移列表：同樣是按照列的順序逆序放置的，若列的長度小於255字節，用1字節表示，若大於255字節，用2字節表示。
2. 記錄頭信息：佔用6字節（48位）
（三）行溢出數據
1. 當行記錄的長度沒有超過行記錄最大長度時，所有數據都會存儲在當前頁。
2. 當行記錄的長度超過行記錄最大長度時，變長列（variable-length column）會選擇外部溢出頁（overflow page，一般是Uncompressed BLOB Page）進行存儲。
Compact + Redundant：保留前768Byte在當前頁（B+Tree葉子節點），其餘數據存放在溢出頁。768Byte後面跟着20Byte的數據，用來存儲指向溢出頁的指針。
（四）概述
對於 Compact 和 Redundant 行格式，InnoDB將變長字段(VARCHAR, VARBINARY, BLOB 和 TEXT)的前786字節存儲在B+樹節點中，其餘的數據存放在溢出頁(off-page)，如下圖：
上面所講的講的blob或變長大字段類型包括blob,text,varchar，其中varchar列值長度大於某數N時也會存溢出頁，在latin1字符集下N值可以這樣計算：innodb的塊大小默認爲16kb，由於innodb存儲引擎表爲索引組織表，樹底層的葉子節點爲一雙向鏈表，因此每個頁中至少應該有兩行記錄，這就決定了innodb在存儲一行數據的時候不能夠超過8k，減去其它列值所佔字節數，約等於N。
使用Antelope文件格式，若字段的值小於等於786字節，不需要溢出頁，因爲字段的值都在B+樹節點中，所以會降低I/O操作。這對於相對較短的BLOB字段有效，但可能由於B+樹節點存儲過多的數據而導致效率低下。
3.2 Compressed 和 Dynamic
InnoDB1.0x開始引入心的文件格式（file format，用戶可以理解位新的頁格式）——Barracuda（圖1），這個新的格式擁有兩種新的行記錄格式：Compressed和Dynamic。
新的兩種記錄格式對於存放BLOB中的數據採用了完全的行溢出的方式。如圖：
Dynamic行格式，列存儲是否放到off-page頁，主要取決於行大小，他會把行中最長的一列放到off-page，直到數據頁能存放下兩行。TEXT或BLOB列<=40bytes時總是存在於數據頁。這種方式可以避免compact那樣把太多的大列值放到B-tree Node（數據頁中只存放20個字節的指針，實際的數據存放在Off Page中，之前的Compact 和 Redundant 兩種格式會存放768個字前綴字節）。
Compressed物理結構上與Dynamic類似，Compressed行記錄格式的另一個功能就是存儲在其中的行數據會以zlib的算法進行壓縮，因此對於BLOB、TEXT、VARCHAR這類大長度數據能夠進行有效的存儲（減少40%，但對CPU要求更高）。
若有不恰當之處，還望指教，謝謝！