MySQL的物理存儲結(jié)構(gòu)和session生命周期

2024-07-24 12:32:28

字體：大中小

供稿：網(wǎng)友

  MySQL的物理存儲結(jié)構(gòu)和session生命周期：

MySQL的物理存儲結(jié)構(gòu)
     (1).數(shù)據(jù)的組織形式--索引

     (2).數(shù)據(jù)的row存儲

compact
變長字段的存儲：

可變長度列在評估字段大小時還要考慮存儲列實際長度的字節(jié)數(shù)。例如，VARCHAR（255）CHARACTER SET UTF8列需要額外的兩個字節(jié)來存儲值長度信息，所以該列需要多達(dá)767個字節(jié)存儲，其實最大可以存儲65533字節(jié)，剩余兩個字節(jié)存儲長度信息。

行溢出的處理：

數(shù)據(jù)表Row_format是Compact， innodb默認(rèn)的approach存儲格式會把每個blob字段的前864個字節(jié)存儲在page里，所以blob超過一定數(shù)量的話，單行大小就會超過8k ，所以就報錯了。通過對比業(yè)務(wù)寫成功和失敗的SQL也應(yīng)征了這個推論，那么現(xiàn)在要怎么解決這個問題？

業(yè)務(wù)拆分表，大字段進(jìn)行分表存儲
通過解決Row_format的存儲方式解決問題由于業(yè)務(wù)單表的存儲條數(shù)并不大，而且業(yè)務(wù)邏輯不適合拆分，所以我們要在Row_format上來解決這個問題。
如果blob列值長度 <= 768 bytes，不會發(fā)生行溢出(page overflow)，內(nèi)容都在數(shù)據(jù)頁(B-tree Node)；如果列值長度 > 768字節(jié)，那么前768字節(jié)依然在數(shù)據(jù)頁，而剩余的則放在溢出頁(off-page)

MySQL的物理存儲結(jié)構(gòu)和session生命周期

所以，此種格式的唯一值索引長度不能超過767

Barracuda

Barracuda文件格式下?lián)碛袃煞N新的行記錄格式Compressed和Dynamic兩種，新的兩種格式對于存放BLOB的數(shù)據(jù)采用了完全的行溢出的方式，在數(shù)據(jù)頁中只存放20個字節(jié)的指針，實際的數(shù)據(jù)都存放在BLOB Page中。Compressed行記錄格式的另一個功能就是存儲在其中的數(shù)據(jù)會以zlib的算法進(jìn)行壓縮。

dynamic行格式，列存儲是否放到off-page頁，主要取決于行大小，它會把行中最長的那一列放到off-page，直到數(shù)據(jù)頁能存放下兩行。TEXT/BLOB列 <=40 bytes 時總是存放于數(shù)據(jù)頁。可以避免compact那樣把太多的大列值放到 B-tree Node，因為dynamic格式認(rèn)為，只要大列值有部分?jǐn)?shù)據(jù)放在off-page，那把整個值放入都放入off-page更有效。

MySQL的物理存儲結(jié)構(gòu)和session生命周期

變長列
在InnoDB中，變長列（
variable-length column
）可能是以下幾種情況

長度不固定的數(shù)據(jù)類型，例如 VARCHAR 、 VARBINARY 、 BLOB 、 TEXT 等
對于長度固定的數(shù)據(jù)類型，如 CHAR ，如果實際存儲占用的空間大于768Byte ，InnoDB會將其視為變長列
變長編碼下的 CHAR。

（編輯：武林網(wǎng)）

上一篇：說Mysql的distinct語句和group by order by

下一篇：CentOS 7下mysql 8修改datadir之后不能啟動