mysql add column_MySQL8.0新特性: Instant Add Column

原标题:MySQL8.0新特性: Instant Add Column

MySQL8.0开始对一些DDL操作做了大量的优化,例如原子DDL, 快速DDL(只修改元数据),前者解决了长期以来mysql的一大诟病,后者则提升了dba同学的生活品质

官方文档列出了一些可以快速ddl的操作,大体包括:

修改索引类型

Add column (limited) 当一条alter语句中同时存在不支持instant的ddl时,则无法使用 只能顺序加列 不支持压缩表 不支持包含全文索引的表 不支持临时表,临时表只能使用copy的方式执行DDL 不支持那些在数据词典表空间中创建的表

修改/删除列的默认值

修改索引类型

修改ENUM/SET类型的定义 存储的大小不变时 向后追加成员

增加或删除类型为virtual的generated column

RENAME TABLE操

本文主要介绍下在MySQL8.0.12引入的快速加列特性。虽然这个特性不能覆盖所有加列场景,但已经能解决很大部分加列带来的问题:

对超级大表的加列操作通常可能耗时几个小时甚至数天的时间

在ddl的过程中产生的临时表会占用磁盘空间

ddl带来的复制延迟问题

具体的worklog为: WL#11250 - Support Instant Add Column,描述的非常详细,本文简单描述下其思路

使用

ALTER语句增加了新的语法INSTANT,你可以显式地指定,但MySQL自身也会自动选择合适的算法。所以这个特性通常对用户是透明的。

增加了一些新的information_schema表来展示相关信息:

9429ae3aef35527714cd6589d9929988.png

举个简单的例子:

ed3384f3ea2f75fddd5ccb9adf2e1833.png

实现

记录格式修改

快速加列特性,在增加列时,实际上只是修改了元数据,原来存储在文件中的行记录并没有被修改。当行格式为redundent类型时,记录解析是不依赖元数据的,可以自解析,

但如果行格式是dynamic或者compact类型,由于行内不存储元数据,尤其是列的个数信息,其记录的解析需要依赖元数据的辅助。因此为了支持动态加列功能,需要对行格式做一定的修改

其大体思路为:

如果表上从未发生过instant add column, 则行格式维持不变。

如果发生过instant ddl, 那么所有新的记录上都被特殊标记了一个flag, 同时在行内存储了列的个数

由于只支持往后顺序加列,通过列的个数就可以知道这个行记录中包含了哪些列的信息

我们先来看看典型compact行类型的记录组织结构:

6ed15d5ea12fadbc949cb10e98d99c63.png

其中extra 5 bytes包含如下信息:

e3737dd5a3d105b355300c40ee8cd2fa.png

extra info中包含的信息如下:

a) Info bits: 4 bits

982dff9cb6638b0a9682db2809b6b709.png

b) Record owned: 4 bits

REC_NEW_N_OWNED

c) Heap No. : 13 bits

d) Record type: 3 bits

82e45d46673dc4c1731d645bef944c02.png

e) Next record ptr: 2 bytes

为了支持instant add column, 使用了info bits中的一个bit位,如果被设置,表示这条记录是第一次instant add column后插入的, flag为:

Ox80: REC_INFO_INSTANT_FLAG

当flag被设置时,在记录中就会使用1或2个字节来存储列的个数

ac404f1084cabb6cc13ef757eca9b3b5.png

对于redundent类型,由于已经有了列个数信息,无需进行修改

数据词典信息

对数据词典进行了扩展并记录:

在第一次instant add column之前的列个数

每次加的列的默认值

通过这些信息加上记录上的额外信息,可以正确解析出记录上的数据

数据词典:

a) dd::Table::se_private_data::instant_col:在第一次instant ADD COLUMN之前表上面的列的个数

b) dd::Partition::se_private_data::instant_col, 和a类似,存储分区表上instant col的个数,但有所不同的是,分区表上的分区之间

可能存在不同列的个数。因为我们单独truncate一个分区,而truncate操作会清空instant标记,因此b)中存储的instant_col不应该比a)中每个分区上的instant_col要小

c) dd::Column::se_private_data::default_null, 表示默认值为NULL

d) dd::Column::se_private_data::default, 当默认值不为null时,这里存储默认值

DD_instant_col_val_coder

--- column default value需要从innodb类型byte转换成se_private_data中的text类型(char), 使用一个类型DD_instant_col_val_coder来辅助转换

example: 0XFF => 0x0F, 0x0F

在将表load到内存建立表对象dict_table_t和索引对象dict_index_t时,有几个关键成员要载入进来,因为会用于辅助解析记录

dict_table_t::n_instant_cols 第一次instant add column之前的非虚拟列个数,(包含系统列

dict_index_t::instant_cols flag用于标示是否存在Instant column

dict_index_t::n_instant_nullable: 第一次instant add column之前的可为null的列个数

dict_col_t::instant_default: 存储默认值及其长度, 当解析数据时看到Instant column, 会直接引用到这里的数据指针

载入逻辑:

1937e756ffdc8cb0ab2241a4e89517cd.png

DDL

检查表是否支持instant ddl

7089292d4e7b92ba46cb13126f668bde.png

condition:

不是压缩表

不是data dictionary tablespace

不是全文索引表

不是临时表

除此之外, 新增列还要确保不改变列的顺序

当判定可以立刻加列时,仅仅需要修改数据词典信息即可

964bfdf9642446337337da5e7c6c752d.png

Note:

truncate操作会重置instant标记

b29d995c6d8f468b5f6c543f0217fe2b.png

2.重建表的话,新不的表将不包含instant列

select

查询的关键在于如何正确的解析出记录中的每一行(对于不在其中的instant column,填默认值即可), 关键的函数是:

b5e458f6f82c80a17b3b8d642b66bd89.png

何时填写instant add的default值:

default值存储在dict_col_t::dict_col_default_t

将默认值填到返回的记录中:

ccd4875b6ca504c51466ba5ef9d0fd30.png

insert

记录在插入之前从tuple转换成physical record:

04afbfdfe099844a15cfa587ab83905e.png

update

对于update,不会把default的值转换成inline的,除非去更新包含default值的列(row_upd_changes_field_size_or_external)

对于update的回滚做了特殊处理:

如果回滚的值从non-default到default值,那么这个是不会存储到列里面去的。(dtuple_t::ignore_trailing_default())

责任编辑:

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

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值