[MySQL 新特性] MySQL5.6 RC的压缩表自适应padding实现

以下是对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进行分裂或不进行合并。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值