以下是对facebook的adaptive padding实现简述，实际上，这是个很小的补丁，并且对OLTP的性能提升效果非常显著（但会影响压缩的效果）。
在5.6.7中引入了facebook对压缩表的改进，其中重要的特性之一就是adaptive padding。
我们知道，在buffer pool中，对一个压缩表的page，同时存在压缩页和非压缩页
–对Page的更改被记录到压缩page的mlog中
–当一个压缩页满时，会进行重压缩
–当重压缩失败时，会分裂压缩页
分裂压缩页的开销很大，需要对原先的压缩page拆分成两个Page，并重新进行压缩，并且会有额外的锁(index rw-lock)开销。
adaptive padding的目的是对一个buffer pool中一个16k的非压缩page”少放一些数据“，来降低压缩失败导致分裂的概率，例如之前会对一个装满16K数据的Page进行压缩，如果pad值为2K，那么会对14K的数据压缩，这会降低压缩失败的概率。
具体实现在函数dict_index_zip_pad_update中，每次压缩成功或失败，都会调用到这个函数。每采样ZIP_PAD_ROUND_LEN（128次）次会进行如下判断：
—当失败率高于
innodb_compression_failure_threshold_pct时，pad+=ZIP_PAD_INCR
—当失败率连续ZIP_PAD_SUCCESSFUL_ROUND_LIMIT(5)次低于
innodb_compression_failure_threshold_pct且pad>0时，pad-= ZIP_PAD_INCR
其中ZIP_PAD_INCR值默认为128
这样就对pad的值实现了动态调整。
函数dict_index_zip_success和dict_index_zip_failure在函数page_zip_compress中对应压缩成功和失败的逻辑被调用。
dict_index_zip_pad_optimal_page_size函数返回减去pad后的page大小，但不得小于(UNIV_PAGE_SIZE * (100 – zip_pad_max)) / 100，在如下函数被调用到：
1.btr_compress //page merge，当page的size小于BTR_CUR_PAGE_COMPRESS_LIMIT时会尝试合并page，purge线程调用btr_cur_pessimistic_delete->btr_cur_compress_if_useful->btr_compress，另外在做btr_cur_pessimistic_update时也可能调用到
2.btr_cur_optimistic_insert //insert操作
3.btr_cur_update_alloc_zip //update操作
通过判断加上新记录后，是否超过optimal page size，如果超过了，则对16k page进行分裂或不进行合并。
