最近在數(shù)據(jù)庫優(yōu)化的時候，看到一些表在設計上使用了text或者blob的字段，單表的存儲空間已經(jīng)達到了近100G，這種情況再去改變和優(yōu)化就非常難了
一、簡介
為了清楚大字段對性能的影響，我們必須要知道innodb存儲引擎的處理方式：
1、一些知識點
1.1 在InnoDB 1.0.x版本之前，InnoDB 存儲引擎提供了 Compact 和 Redundant（Redundant 格式是為兼容之前版本而保留的） 兩種格式來存放行記錄數(shù)據(jù)，compact 和 redundant 合稱為Antelope (羚羊)
對于blob，text，varchar(5120)這樣的大字段，innodb只會存放前768字節(jié)在數(shù)據(jù)頁中，而剩余的數(shù)據(jù)則會存儲在溢出段中（發(fā)生溢出情況的時候適用），最大768字節(jié)的作用是便于創(chuàng)建前綴索引/prefix index，其余更多的內(nèi)容存儲在額外的page里，哪怕只是多了一個字節(jié)。因此，所有列長度越短越好
大字段在InnoDB里可能浪費大量空間。例如，若存儲字段值只是比行的要求多了一個字節(jié)，也會使用整個頁面來存儲剩下的字節(jié)，浪費了頁面的大部分空間。如果有一個值只是稍微超過了32個頁的大小，實際上就需要使用96個頁面
擴展存儲禁用了自適應哈希，因為需要完整的比較列的整個長度，才能發(fā)現(xiàn)是不是正確的數(shù)據(jù)（哈希幫助InnoDB非?？焖俚恼业健安聹y的位置”，但是必須檢查“猜測的位置”是不是正確）。因為自適應哈希是完全的內(nèi)存結(jié)構(gòu)，并且直接指向Buffer Pool中訪問“最”頻繁的頁面，但對于擴展存儲空間卻無法使用Adaptive Hash
1.2 MySQL 5.1 中的 innodb_plugin 引入了新的文件格式：Barracuda (梭子魚)，該文件格式擁有新的兩種行格式：compressed和dynamic，兩種格式對blob字段采用完全溢出的方式，數(shù)據(jù)頁中只存放20字節(jié)，其余的都存放在溢出段中，因此，強烈不建議使用BLOB、TEXT、超過255長度的VARCHAR列類型；
1.3 innodb的page大小默認為16kb，innodb存儲引擎表為索引組織表，樹底層的葉子節(jié)點為一雙向鏈表，因此每個頁中至少應該有兩行記錄，這就決定了innodb在存儲一行數(shù)據(jù)的時候不能夠超過8k，但事實上應該更小，因為還有一些InnoDB內(nèi)部數(shù)據(jù)結(jié)構(gòu)要存儲，5.6版本以后，新增選項 innodb_page_size 可以修改，在5.6以前的版本，只能修改源碼重新編譯，但并不推薦修改這個配置
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學習是年輕人改變自己的最好方式