从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手册：
本文出自 “贺春旸的技术专栏” 博客，请务必保留此出处