从MySQL5.5.X版本开始，支持InnoDB数据页压缩，数据页的压缩使数据文件体积变小，减少磁盘I/O，提高吞吐量，小成本的提高CPU利用率。尤其是对读多写少的应用，最

从MySQL5.5.X版本开始，支持InnoDB数据页压缩，服务器租用，数据页的压缩使数据文件体积变小，减少磁盘I/O，提高吞吐量，小成本的提高CPU利用率。尤其是对读多写少的应用，最为有效，同样的内存可以存储更多的数据，充分的“榨干”内存利用率。

它的工作原理是：当用户获取数据时，如果压缩的页没有在Innodb_Buffer_Pool缓冲池里，空间，那么会从磁盘加载进去，并且在Innodb_Buffer_Pool缓冲池里开辟一个新的未压缩16K的数据页来解压缩加载进来的压缩页，为了减少磁盘I/O以及对页的解压，在缓冲池里同时存在压缩和未压缩的页。为了给其他需要的数据页腾出空间，缓冲池里会把未压缩的数据页踢出去，而保留压缩的页在内存，未压缩的页在一段时间内没有被访问，那么会直接写入磁盘里，因此缓冲池里中可能有压缩和未压缩的页，或者只有压缩页。

Innodb采用最近最少使用(LRU)算法，将经常被访问的热数据放入内存里。当访问一个压缩表时，Innodb使用一个自适应的LRU算法来实现内存中压缩页和未压缩页一个适当的平衡，其目的是为了避免当CPU繁忙时花费太多的时间用在解压缩上，也为了避免当CPU空闲时做过多的I/O操作在解压缩上。所以，当系统处于I/O瓶颈时，这个算法会踢出未压缩的页，而不是压缩的页，为了让更多的页注入内存腾出空间。当系统处于CPU瓶颈时，这个算法会同时踢出未压缩的页和压缩的页，让更多的内存存放热数据，减少解压缩带来的开销。

在以前的版本，一个数据页是16K，现在可以在建表时指定压缩的页是1,2,4,8K，设置过小，会导致消耗更多的CPU，通常设置为8K。

注：必须采用文件格式Barracuda，且表空间才支持数据页压缩。

在建表的时候加入ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8即可，如：

针对数据页8K和16K，进行了一次压力测试，虚拟机内存1G，Buffer_Pool为600M。

先创建1千万行记录的表，经过压缩的8K数据页的表要比未压缩16K的数据页体积小一半。

左图为未压缩，右图为压缩

从图中所看，被请求的数据页小于InnoDB_Buffer_Pool缓冲池大小，未压缩的性能要稍好于压缩过的，因为压缩会带来额外的CPU消耗，总体上差异不大。

下面把Sysbench参数调大，再压一次

左图为未压缩16K，右图为压缩8K

从图中所看，被请求的数据页大于InnoDB_Buffer_Pool缓冲池大小，压缩的性能要好于未压缩过的，吞吐量也提高，最为明显CPU Wait/IO降低很多。

根据以上两种情况，你可根据自身的业务情况，来选择是否开启数据页压缩功能。

另附上大批量插入时的测试：

在大批量插入的时候，空间，几乎慢了1倍，8K数据页性能要比16K数据页性能有所下降。

参见MySQL5.5手册：

本文出自 “贺春旸的技术专栏” 博客，请务必保留此出处