[MySQL源码] Facebook对压缩表的改进

由于公司最近很多地方需要开始有使用压缩表的需求，但根据测试结果，压缩表对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

3.增加adpative padding功能，减少每个page上的数据来降低压缩失败率

类似于在page上填写空白，当压缩失败率升高到某个层次时，加大pad值。当失败率维持在很低的水平时，则减小pad值。

4.减少分配的空白页，以降低文件的大小

<a href="http://www.facebook.com/l.php?u=http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/5.1/revision/3814&amp;h=6aqeg8hsi&amp;s=1" target="_blank">r3814</a>

5.减少压缩page的malloc/free次数

6.更高效的压缩page checksum

8.允许设置zlib的压缩级别

10.其他