如何優化InnoDB表BLOB,TEXT列的存儲效率

這篇文章主要介紹了如何優化InnoDB表BLOB,TEXT列的存儲效率，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

首先，介紹下關于MySQL InnoDB引擎存儲格式的幾個要點：

1、InnoDB可以選擇使用共享表空間或者是獨立表空間方式，建議使用獨立表空間，便于管理、維護。啟用 innodb_file_per_table 選項，5.5以后可以在線動態修改生效，并且執行 ALTER TABLE xx ENGINE = InnoDB 將現有表轉成獨立表空間，早于5.5的版本，修改完這個選項后，需要重啟才能生效。

2、InnoDB的data page默認16KB，5.6版本以后，新增選項 innodb_page_size 可以修改，在5.6以前的版本，只能修改源碼重新編譯，但并不推薦修改這個配置，除非你非常清楚它有什么優缺點。

3、InnoDB的data page在有新數據寫入時，會預留1/16的空間，預留出來的空間可用于后續的新紀錄寫入，減少頻繁的新增data page的開銷。

4、每個data page，至少需要存儲2行記錄。因此理論上行記錄最大長度為8KB，但事實上應該更小，因為還有一些InnoDB內部數據結構要存儲。

5、受限于InnoDB存儲方式，如果數據是順序寫入的話，最理想的情況下，data page的填充率是15/16，但一般沒辦法保證完全的順序寫入，因此，data page的填充率一般是1/2到15/16。因此每個InnoDB表都最好要有一個自增列作為主鍵，使得新紀錄寫入盡可能是順序的。

6、當data page填充率不足1/2時，InnoDB會進行收縮，釋放空閑空間。

7、MySQL 5.6版本的InnoDB引擎當前支持COMPACT、REDUNDANT、DYNAMIC、COMPRESSED四種格式，默認是COMPACT格式，COMPRESSED用的很少且不推薦（見下一條），如果需要用到壓縮特性的話，可以直接考慮TokuDB引擎。

8、COMPACT行格式相比REDUNDANT，大概能節省20%的存儲空間，COMPRESSED相比COMPACT大概能節省50%的存儲空間，但會導致TPS下降了90%。因此強烈不推薦使用COMPRESSED行格式。

9、當行格式為DYNAMIC或COMPRESSED時，TEXT/BLOB之類的長列（long column，也有可能是其他較長的列，不一定只有TEXT/BLOB類型，看具體情況）會完全存儲在一個獨立的data page里，聚集索引頁中只使用20字節的指針指向新的page，這就是所謂的off-page，類似ORACLE的行遷移，磁盤空間浪費較嚴重，且I/O性能也較差。因此，強烈不建議使用BLOB、TEXT、超過255長度的VARCHAR列類型。

10、當InnoDB的文件格式（innodb_file_format）設置為Antelope，并且行格式為COMPACT 或 REDUNDANT 時，BLOB、TEXT或者長VARCHAR列只會將其前768字節存儲在聚集索頁中（最大768字節的作用是便于創建前綴索引/prefix index），其余更多的內容存儲在額外的page里，哪怕只是多了一個字節。因此，所有列長度越短越好。

11、在off-page中存儲的BLOB、TEXT或者長VARCHAR列的page是獨享的，不能共享。因此強烈不建議在一個表中使用多個長列。

綜上，如果在實際業務中，確實需要在InnoDB表中存儲BLOB、TEXT、長VARCHAR列時，有下面幾點建議：

1、盡可能將所有數據序列化、壓縮之后，存儲在同一個列里，避免發生多次off-page。

2、實際最大存儲長度低于255的列，轉成VARCHAR或者CHAR類型（如果是變長數據二者沒區別，如果是定長數據，則使用CHAR類型）。

3、如果無法將所有列整合到一個列，可以退而求其次，根據每個列最大長度進行排列組合后拆分成多個子表，盡量是的每個子表的總行長度小于8KB，減少發生off-page的頻率。

4、上述建議是在data page為默認的16KB前提下，如果修改成8KB或者其他大小，請自行根據上述理論進行測試，找到最合適的值。

5、字符型列長度小于255時，無論采用CHAR還是VARCHAR來存儲，或者把VARCHAR列長度定義為255，都不會導致實際表空間增大。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“如何優化InnoDB表BLOB,TEXT列的存儲效率”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!