由于公司最近很多地方需要开始有使用压缩表的需求，但根据测试结果，压缩表对OLTP的性能相当不理想，在最近的一次测试中，UPDATE的性能最大可以下降到1/12，几乎不可接受。
Facebook从2011年开始对压缩表进行改进，花了两个星期从facebook的博客、facebook成员在官方list上提交的bug以及Mark在lauchpad上提交的patch着手调研，以下内容基本涵盖了Facebook对压缩表的改进，以及对应的Rev
接下来，需要做的就是研究这些Patch，如何为我所用。
注：除了以下内容，在查看facebook的bzr log时，还发现很多比较小的优化点（例如对innodb层线程调度的改进），但未公布出来，有兴趣的可以看看。
1.提供更多的信息来监控/诊断压缩表性能
MySQL本身（包括Percona版本）提供的压缩表内部信息非常少，很难通过这些信息来进行优化，Facebook增加了大量的信息用以显示。
从mysql@facebook的代码来看，为table_statistics增加了大量的统计数据，包括IO、索引、压缩表相关信息，我们关注如下几个跟压缩表相关的信息：
COMPRESSED_PAGE_SIZE COMPRESS_PADDING PADDING_SAVINGS COMPRESS_OPS
COMPRESS_OPS_OK COMPRESS_PRIMARY_OPS COMPRESS_PRIMARY_OPS_OK
COMPRESS_USECS COMPRESS_OK_USECS COMPRESS_PRIMARY_USECS
COMPRESS_PRIMARY_OK_USECS UNCOMPRESS_OPS UNCOMPRESS_USECS
另外在update_global_table_stats函数中，facebook做了一些优化，通过原子操作代替锁操作，避免长期持有全局锁 LOCK_global_table_stats
扩展innodb_cmp表的信息 r3679
更多的global status信息 r3672，r3671
2.从redo log中移除压缩Page，并为压缩表增加了一种新的日志记录 –r3641
3.增加adpative padding功能，减少每个page上的数据来降低压缩失败率
类似于在page上填写空白，当压缩失败率升高到某个层次时，加大pad值。当失败率维持在很低的水平时，则减小pad值。
动态padding实现 r3754, r3759, r3764, r3768
线性算法计算自适应padding值 r3820
4.减少分配的空白页，以降低文件的大小
相关bug： bug#64673
5.减少压缩Page的malloc/free次数
避免每次page 压缩/解压时频繁malloc/free 内存 r3808
6.更高效的压缩page checksum
对压缩page使用快速checksum r3824 related bug#49852
通过只在需要的时候计算压缩page/非压缩page的checksum来降低cpu占用 r3816 ， r3817 related bug#64170
7.移除对adler32的调用 r3818
8.允许设置zlib的压缩级别
增加了新的参数innodb_compression_level来控制zlib的压缩级别 r3766
10.其他
增加innochecksum工具对压缩表的支持 r3813
Fix bug#64258 可动态调整WAIT_FOR_READ r3792
跟压缩表相关，未具说明的bugfix r3779， r3780 （maybe related to bug#61208）