MySQL的物理儲存結構和session過程

1.  MySQL的物理儲存結構

     (1).資料的組織形式--索引

     (2).資料的row儲存

compact

變長欄位的儲存：

可變長度列在評估欄位大小時還要考慮儲存列實際長度的位元組數。例如，VARCHAR（255）CHARACTER SET UTF8列需要額外的兩個位元組來儲存值長度資訊，所以該列需要多達767個位元組儲存，其實最大可以儲存65533位元組，剩餘兩個位元組儲存長度資訊。

行溢位的處理：

資料表Row_format是Compact， innodb預設的approach儲存格式會把每個blob欄位的前864個位元組儲存在page裡，所以blob超過一定數量的話，單行大小就會超過8k ，所以就報錯了。通過對比業務寫成功和失敗的SQL也應徵了這個推論，那麼現在要怎麼解決這個問題？

• 業務拆分表，大欄位進行分表儲存
• 通過解決Row_format的儲存方式解決問題

  由於業務單表的儲存條數並不大，而且業務邏輯不適合拆分，所以我們要在Row_format上來解決這個問題。

如果blob列值長度 <= 768 bytes，不會發生行溢位(page overflow)，內容都在資料頁(B-tree Node)；如果列值長度 > 768位元組，那麼前768位元組依然在資料頁，而剩餘的則放在溢位頁(off-page)

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

Barracuda

Barracuda檔案格式下擁有兩種新的行記錄格式Compressed和Dynamic兩種，新的兩種格式對於存放BLOB的資料採用了完全的行溢位的方式，在資料頁中只存放20個位元組的指標，實際的資料都存放在BLOB Page中。Compressed行記錄格式的另一個功能就是儲存在其中的資料會以zlib的演算法進行壓縮。

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

變長列

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

1. 長度不固定 的資料型別，例如 VARCHAR 、 VARBINARY 、 BLOB 、 TEXT 等
2. 對於 長度固定 的資料型別，如 CHAR ，如果 實際儲存 佔用的空間 大於768Byte ，InnoDB會將其視為變長列
3. 變長編碼 下的 CHAR

NULL值標識位

指示了該行資料列中是否有NULL值，這個欄位的長度和表的列數有關，每一列對應一個bit位

     2. session的執行過程

     

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25380026/viewspace-2643521/，如需轉載，請註明出處，否則將追究法律責任。