5.6.7已经RC，其中关于压缩表部分，引进了大多数Facebook的改进
1.可配置的zlib压缩级别 innodb_compression_level
用于动态调整zlib的压缩级别，从1-9，默认为6，越小压缩效果越差，但压缩速度越快；值越大，压缩效果越好，可能会减小压缩失败及page split， 但速度越慢，有更多的CPU开销。
2. innodb_log_compressed_pages
控制压缩page是否被记录到redo中，这会减少redo产生的数据量，可能会提升throughput
3.增加adaptive padding功能，通过在page中留下空白来防止减少page分裂，Facebook的实现是在启动mysqld后，对压缩表中的压缩失败的page进行采样，以计算出合适的留白数。
增加了两个参数：
innodb_compression_failure_threshold_pct 当压缩失败rate大于这个值时，会增加padding来减小失败率，为0表示禁止该padding.（官方文档貌似有误，已report）
innodb_compression_pad_pct_max 一个page中最大允许留白的百分比
4.新的关于压缩表的i_s表：
innodb_cmp_per_index_reset
由于这些表里记载了每个索引的压缩信息，因此会产生一些额外的开销，通过选项 innodb_cmp_per_index_enabled 来控制开关
例如：
mysql> select * from innodb_cmp_per_index\G
*************************** 1. row ***************************
database_name: cmp2k8
table_name: com1@@@
index_name: PRIMARY
compress_ops: 34999
compress_ops_ok: 34150
compress_time: 13
uncompress_ops: 424
uncompress_time: 0
1 row in set (0.00 sec)
innodb_cmp_per_index_reset跟 innodb_cmp_per_index差不多，区别就是每次查询时会重置之前的统计。
简单的load数据来看，效果还是很明显的，
5.6.6—1622 rows/s
5.6.7—6500 rows/s
接下来，开始将这些改进backport到我们的线上版本5.5.18中