最近在數據庫優(yōu)化的時候，看到一些表在設計上使用了text或者blob的字段，單表的存儲空間已經達到了近100G，這種情況再去改變和優(yōu)化就非常難了
一、簡介
為了清楚大字段對性能的影響，我們必須要知道innodb存儲引擎的處理方式：
1、一些知識點
1.1 在InnoDB 1.0.x版本之前，InnoDB 存儲引擎提供了 Compact 和 Redundant（Redundant 格式是為兼容之前版本而保留的） 兩種格式來存放行記錄數據，compact 和 redundant 合稱為Antelope (羚羊)
對于blob，text，varchar(5120)這樣的大字段，innodb只會存放前768字節(jié)在數據頁中，而剩余的數據則會存儲在溢出段中（發(fā)生溢出情況的時候適用），最大768字節(jié)的作用是便于創(chuàng)建前綴索引/prefix index，其余更多的內容存儲在額外的page里，哪怕只是多了一個字節(jié)。因此，所有列長度越短越好
大字段在InnoDB里可能浪費大量空間。例如，若存儲字段值只是比行的要求多了一個字節(jié)，也會使用整個頁面來存儲剩下的字節(jié)，浪費了頁面的大部分空間。如果有一個值只是稍微超過了32個頁的大小，實際上就需要使用96個頁面
擴展存儲禁用了自適應哈希，因為需要完整的比較列的整個長度，才能發(fā)現(xiàn)是不是正確的數據（哈希幫助InnoDB非常快速的找到“猜測的位置”，但是必須檢查“猜測的位置”是不是正確）。因為自適應哈希是完全的內存結構，并且直接指向Buffer Pool中訪問“最”頻繁的頁面，但對于擴展存儲空間卻無法使用Adaptive Hash
1.2 MySQL 5.1 中的 innodb_plugin 引入了新的文件格式：Barracuda (梭子魚)，該文件格式擁有新的兩種行格式：compressed和dynamic，兩種格式對blob字段采用完全溢出的方式，數據頁中只存放20字節(jié)，其余的都存放在溢出段中，因此，強烈不建議使用BLOB、TEXT、超過255長度的VARCHAR列類型；
1.3 innodb的page大小默認為16kb，innodb存儲引擎表為索引組織表，樹底層的葉子節(jié)點為一雙向鏈表，因此每個頁中至少應該有兩行記錄，這就決定了innodb在存儲一行數據的時候不能夠超過8k，但事實上應該更小，因為還有一些InnoDB內部數據結構要存儲，5.6版本以后，新增選項 innodb_page_size 可以修改，在5.6以前的版本，只能修改源碼重新編譯，但并不推薦修改這個配置
