最近在數(shù)據(jù)庫優(yōu)化的時(shí)候，看到一些表在設(shè)計(jì)上使用了text或者blob的字段，單表的存儲(chǔ)空間已經(jīng)達(dá)到了近100G，這種情況再去改變和優(yōu)化就非常難了

一、簡介

為了清楚大字段對(duì)性能的影響，我們必須要知道innodb存儲(chǔ)引擎的處理方式：

1、一些知識(shí)點(diǎn) 

1.1 在InnoDB 1.0.x版本之前，InnoDB 存儲(chǔ)引擎提供了 Compact 和 Redundant（Redundant 格式是為兼容之前版本而保留的） 兩種格式來存放行記錄數(shù)據(jù)，compact 和 redundant 合稱為Antelope (羚羊)

對(duì)于blob，text，varchar(5120)這樣的大字段，innodb只會(huì)存放前768字節(jié)在數(shù)據(jù)頁中，而剩余的數(shù)據(jù)則會(huì)存儲(chǔ)在溢出段中（發(fā)生溢出情況的時(shí)候適用），最大768字節(jié)的作用是便于創(chuàng)建前綴索引/prefix index，其余更多的內(nèi)容存儲(chǔ)在額外的page里，哪怕只是多了一個(gè)字節(jié)。因此，所有列長度越短越好

  • 大字段在InnoDB里可能浪費(fèi)大量空間。例如，若存儲(chǔ)字段值只是比行的要求多了一個(gè)字節(jié)，也會(huì)使用整個(gè)頁面來存儲(chǔ)剩下的字節(jié)，浪費(fèi)了頁面的大部分空間。如果有一個(gè)值只是稍微超過了32個(gè)頁的大小，實(shí)際上就需要使用96個(gè)頁面

  • 擴(kuò)展存儲(chǔ)禁用了自適應(yīng)哈希，因?yàn)樾枰暾谋容^列的整個(gè)長度，才能發(fā)現(xiàn)是不是正確的數(shù)據(jù)（哈希幫助InnoDB非?？焖俚恼业健安聹y(cè)的位置”，但是必須檢查“猜測(cè)的位置”是不是正確）。因?yàn)樽赃m應(yīng)哈希是完全的內(nèi)存結(jié)構(gòu)，并且直接指向Buffer Pool中訪問“最”頻繁的頁面，但對(duì)于擴(kuò)展存儲(chǔ)空間卻無法使用Adaptive Hash

電腦培訓(xùn),計(jì)算機(jī)培訓(xùn),平面設(shè)計(jì)培訓(xùn),網(wǎng)頁設(shè)計(jì)培訓(xùn),美工培訓(xùn),Web培訓(xùn),Web前端開發(fā)培訓(xùn)

 

1.2 MySQL 5.1 中的 innodb_plugin 引入了新的文件格式：Barracuda (梭子魚)，該文件格式擁有新的兩種行格式：compressed和dynamic，兩種格式對(duì)blob字段采用完全溢出的方式，數(shù)據(jù)頁中只存放20字節(jié)，其余的都存放在溢出段中，因此，強(qiáng)烈不建議使用BLOB、TEXT、超過255長度的VARCHAR列類型；

電腦培訓(xùn),計(jì)算機(jī)培訓(xùn),平面設(shè)計(jì)培訓(xùn),網(wǎng)頁設(shè)計(jì)培訓(xùn),美工培訓(xùn),Web培訓(xùn),Web前端開發(fā)培訓(xùn)

1.3 innodb的page大小默認(rèn)為16kb，innodb存儲(chǔ)引擎表為索引組織表，樹底層的葉子節(jié)點(diǎn)為一雙向鏈表，因此每個(gè)頁中至少應(yīng)該有兩行記錄，這就決定了innodb在存儲(chǔ)一行數(shù)據(jù)的時(shí)候不能夠超過8k，但事實(shí)上應(yīng)該更小，因?yàn)檫€有一些InnoDB內(nèi)部數(shù)據(jù)結(jié)構(gòu)要存儲(chǔ)，5.6版本以后，新增選項(xiàng) innodb_page_size 可以修改，在5.6以前的版本，只能修改源碼重新編譯，但并不推薦修改這個(gè)配置

延伸閱讀

學(xué)習(xí)是年輕人改變自己的最好方式-Java培訓(xùn),做最負(fù)責(zé)任的教育,學(xué)習(xí)改變命運(yùn),軟件學(xué)習(xí),再就業(yè),大學(xué)生如何就業(yè),幫大學(xué)生找到好工作,lphotoshop培訓(xùn),電腦培訓(xùn),電腦維修培訓(xùn),移動(dòng)軟件開發(fā)培訓(xùn),網(wǎng)站設(shè)計(jì)培訓(xùn),網(wǎng)站建設(shè)培訓(xùn)學(xué)習(xí)是年輕人改變自己的最好方式