以下是在閱讀官方文件時的筆記
官方文件:
關於壓縮表，可以調整的引數看起來只有key_block_size
，在建表時指定，意味著
innodb
會將page
壓縮到指定的大小，例如，如果設定
key_block_size=8
，則將其壓縮到8k。
key_block_size
的值應根據記錄的長度來確定，如果設定的過小，可能由於乙個
page
無法壓縮太多行而出現高概率的壓縮失敗，導致不得不
split page.
但設定為
16k則不會取得太好的壓縮效果，當然這種情況依然對存在長
blob/varchar/text
型別的列有好處，這可以避免過多的」overflow」 page
在buffer pool
中，壓縮資料也以小
page
的形式存在，為了獲取或更新資料，在
innodb
中也為解壓資料建立了
16kb
的page
，任何對解壓
page
的修改，也會寫入到壓縮
page
中。當空間不夠時，解壓
page
會被驅逐出bp。
注意實際的壓縮演算法並不受key_block_size
的影響。
key_block_size的預設值為8k。
在表上建立索引時create index
指定row_format
和key_block_size
沒有效果，這取決於建表時的設定。
總的來說，壓縮表更加適用於合理長度的字串，並且其資料讀比寫更多。何時使用壓縮表並無定論，這取決於你的負載和資料集合，或者特定的配置。可以考慮如下因素：
a.由於壓縮本身通過識別資料塊中的重複字串來進行壓縮，完全隨機的資料可能會得到很差的效果。典型的資料通常有很多重複，因此能獲得更好的壓縮效果。字串(char, varchar, text
或者 blob)
可以獲得更好的效果。
可以從乙個非壓縮表中拷貝資料到乙個相同的壓縮表中，觀察資料大小，來決定是否適合壓縮。在innodb_cmp
中，通過觀察
compress_ops_ok/compress_ops
來獲得壓縮成功率。如果該比率較高，則表明適合作為壓縮表。
b.已經在應用中壓縮過的資料，不適合儲存到壓縮表中。
c.通過like
或order by
來測試壓縮後的索引效能
d.在應用中進行壓縮(使用mysql提供的compress/uncompress函式進行壓縮/解壓)
e.在表上的workload
是乙個關鍵性因素，如果更新主要作用在外部儲存的長字串的非索引列上，壓縮的開銷可能是可以接受的。如果你的負載是
i/o bound
而非cpu bound
的，壓縮可能會改善整體效能。
f.配置特性；壓縮可以通過消耗cpu
來減少io
，如果io
是相對緊缺的資源時，會獲得更好的效果。
g.選擇壓縮page
的大小應該比記錄更大，否則可能會引起大量的壓縮失敗。通常情況下
key_block_size=8
是比較安全的設定。
h.執行時監控壓縮
a.cpu和
io利用率，資料檔案大小等
b.通過innodb_cmp/innodb_cmp_reset
表進行監控，如果
compress_ops_ok/compress_ops
的比率較高，說明系統工作的很好，如果很低，則表明
innodb
可能有太多的重新組織，重新壓縮或
b-tree
節點**。這種情況下避免壓縮這些表，或調大
key_block_size
的值。
###壓縮表內部實現
tips###
innodb使用的是
zlib
中的lz77演算法
b-tree node中的某些系統資訊並未壓縮，這有利於
in-place update
，例如標記刪除以及無需解壓的刪除操作。
為了避免dml
產生的過多的解壓
/壓縮，在每個
b-tree page
中，維持了一段非壓縮的「
modification log
」，來記錄
page
上的更改。
當「modification log
」過大時，
innodb
會解壓page
，執行更新，然後重新壓縮
page
。如果重新壓縮失敗，就需要**
b樹節點。
通常情況下innodb
要求每個
page
至少容納
2條記錄，對於壓縮表，這個限制被放鬆了，葉子節點可以只容納一條記錄，但是
but that record must fit in uncompressed form, in the per-page modification log(
暫時沒搞明白，待分析)
為了減少io
和解壓page
的次數，在
buffer pool
中可能會維護
page
的壓縮和解壓兩類，當空間不夠時，
innodb
可能將解壓的
page
驅逐掉，保留壓縮的
page在bp
中。如果乙個
page
在一段時間內沒有被使用，壓縮格式的
page
也會被寫會到磁碟中，以釋放空間。
innodb使用乙個
adaptive lru
演算法來維持記憶體內壓縮和非壓縮
page
的平衡，目的是為了避免在
cpu繁忙時減少解壓
page
的開銷，當
cpu富餘時避免過多的
i/o。當系統是
i/o bound
時，傾向於選擇驅逐
page
的非壓縮拷貝，以留下空間給其他讀入磁碟的
page
。當是cpu bound
時，innodb
選擇驅逐壓縮和非壓縮這兩種
page
，這樣記憶體可以更多的留給「
hot page
」，並減少記憶體中需要解壓的page。
mysql 表空間收縮 mysql壓縮表空間
repair table table name 修復表 optimize table table name 優化表 optimize local no write to binlog table tbl name tbl name 如果您已經刪除了表的一大部分，或者如果您已經對含有可變長度行的表 含...
mysql 索引壓縮 MySQL 索引壓縮碎片
mysql 索引簡介 索引也叫 鍵 key 是儲存引擎用於快速找到記錄的一種資料結構。索引對於良好的效能非常關鍵。資料量越來越大的時候，索引的重要性也會體現出來。例如下面的sql select from user where userid 123 如果沒有建立索引，此時查詢會全表掃瞄 如果在user...
MYSQL表的型別 靜態表 動態表 壓縮表
mysql在建立表的時候定義表的性質，共有三種 靜態表，動態表，壓縮表。預設是靜態表，如果存在varchar blob text欄位，表型別就是動態了。1.靜態表 欄位有固定長度，例如 char 20 如果使用gbk字符集儲存中文username，將占用40byte，如果username的實際內容沒...