[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进行分裂或不进行合并。

时间: 2016-05-10

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

MySQL · 新特性分析 · 5.7中Derived table变形记

Derived table实际上是一种特殊的subquery,它位于SQL语句中FROM子句里面,可以看做是一个单独的表.MySQL5.7之前的处理都是对Derived table进行Materialize,生成一个临时表保存Derived table的结果,然后利用临时表来协助完成其他父查询的操作,比如JOIN等操作.MySQL5.7中对Derived table做了一个新特性.该特性允许将符合条件的Derived table中的子表与父查询的表合并进行直接JOIN.下面我们看一下DBT-3中

[MySQL 特性] MySQL5.6.7 对压缩表的改进

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产生的数据量,可能会提升throughp

MySQL · 引擎特性 · MySQL5.7 崩溃恢复优化

在MySQL5.7之前的版本中, InnoDB每次做crash recovery之前都需要扫描数据目录,打开每个文件并创建内存对象.当目录下文件个数特别多时,会严重影响到崩溃恢复的速度. 为了解决这个问题,MySQL5.7通过结合checkpoint + 标注被修改的文件的方式,从一个checkpoint点开始,可以找到所有崩溃恢复需要打开的文件,从而避免扫描数据目录. 本文简单的记录了相关的代码,以及一个相关的优化点. 提交mini transaction 入口函数: mtr_commit -

MYSQL · 新特性 · MySQL 8.0对Parser所做的改进

背景介绍 众所周知,MySQL Parser是利用C/C++实现的开源yacc/lex组合,也就是 GNU bison/flex.Flex负责生成tokens, Bison负责语法解析.开始介绍MySQL 8.0的新特新之前,我们先简单了解一下通用的两种Parser.一种是Bottom-up parser,另外一种是Top-down parser. Bottom-up parser Bottom-up解析是从parse tree底层开始向上构造,然后将每个token移进(shift),进而规约(

PostgreSQL 10 新特性, 流式接收端在线压缩redo

标签 PostgreSQL , redo 在线压缩 , wal 在线压缩 , 接收端压缩 , pg_receivexlog , pg_basebackup , 断点续传 背景 虽然现在磁盘已经很廉价,大多数时候不需要压缩了. 但是在一些嵌入式系统,或者一些未扩容的产品环境中,压缩还是非常有必要的. 特别是数据变化大.或者数据增量大的场景,例如物联网(IoT),每天单库可能新增TB级的增量. 比如 <PostgreSQL 如何潇洒的处理每天上百TB的数据增量> 指的就是IoT场景. 这样的场景,

ThinkPHP3.1新特性之对页面压缩输出的支持_php实例

目前大多数浏览器都已经支持页面的压缩输出,通过压缩输出,页面大小可以减少30%,但是由于3.0及以前的版本都没有内置页面压缩输出功能,所以一般来说,开发人员需要自己在入口文件中添加: ob_start('ob_gzhandler'); 但是由于服务器环境的不同,有时候这个配置会和php.ini文件中的zlib压缩配置冲突.而ThinkPHP3.1版则内置了页面压缩输出的功能,不再需要再手动添加ob_gzhandler代码,增加OUTPUT_ENCODE配置参数,并支持检测zlib.output_

【MySQL】MySQL5.6新特性之crash-safe

一 介绍  MySQL 5.6 针对复制功能提供了新特性: slave支持crash-safe. 该功能可以解决之前版本中系统异常断电可能导致的SQL thread 信息不准确的问题.本文从原理方面对该特性进行介绍.二 原理  在了解crash-safe slave 之前,我们先分析一下MySQL 5.6 之前的版本出现 crash-unsafe 的原因.在slave上,复制包含两个线程:即replication中的IO thread和SQL thread.IO thread负责从master拷

【MySQL】MySQL5.6新特性之Index Condition Pushdown

一 概念介绍    Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式.a 当关闭ICP时,index 仅仅是data access 的一种访问方式,存储引擎通过索引回表获取的数据会传递到MySQL Server 层进行where条件过滤.b 当打开ICP时,如果部分where条件能使用索引中的字段,MySQL Server 会把这部分下推到引擎层,可以利用index过滤的where条件在存储引擎层进

MySQL5.7中InnoDB不可不知的新特性

讲师介绍  赖铮Oracle InnoDB团队 Principle Software Developer   曾任达梦.Teradata高级工程师,主要负责研发数据库执行引擎和存储引擎,十年以商数据库内核开发经验.    大家好,首先非常感谢社群的引荐,让我有机会在这里跟广大的DBA群友们交流.   今天的分享主要是针对MySQL5.7中InnoDB的新特性,InnoDB大家都应该非常熟悉,作为MySQL的存储引擎,而且现在变成默认的存储引擎,它为MySQL提供了强大的存储支持.伴随着MySQL