{{ item.name }}
{{ item.name }}

{{ it.name }}

{{ it.text }}

{{ it.name }}

{{ innerIt.name }}

{{ innerIt.text }}

{{news.time}}
{{news.title}}
MySQL 为表添加列 是怎么“立刻”完成的
2020-05-14发布 1,000浏览

在上一期图解 图解MySQL | MySQL DDL为什么成本高?中,我们介绍了:

  • 传统情况下,为表添加列需要对表进行重建

  • 腾讯团队为 MySQL 引入了 Instant Add Column 的方案(以下称为 "立刻加列" 功能)可以快速完成 为表添加列 的任务


同时我们留了以下思考题:

  • "立刻加列" 是如何工作的 ?

  • 所谓 "立刻加列" 是否完全不影响业务,是否是真正的 "立刻" 完成 ?


本期我们针对这几个问题来进行讨论:


传统情况

我们先回顾一下,在没有 "立刻加列" 功能时,加列操作是怎么完成的。我们也借此来熟悉一下本期的图例:

MySQL 为表添加列 是怎么“立刻”完成的-爱可生


  • 当进行 加列操作 时,所有的数据行 都必须要 增加一段数据(图中的 列 4 数据)

  • 如上一期图解所讲,当改变数据行的长度,就需要 重建表空间(图中灰蓝的部分为发生变更的部分)

  • 数据字典中的列定义也会被更新

以上操作的问题在于 每次加列 操作都需要重建表空间,这就需要大量 IO以及大量的时间


立刻加列

"立刻加列" 的过程如下图:

MySQL 为表添加列 是怎么“立刻”完成的-爱可生


  • "立刻加列" 时,只会变更数据字典中的内容,包括:

    • 列定义中增加 新列的定义

    • 增加 新列的默认值

  • "立刻加列" 后,当要读取表中的数据时:

    • 由于 "立刻加列" 没有 变更行数据,读取的行数据只有 3 列

    • MySQL 会将 新增的第 4 列的默认值,追加到 读取的数据后


以上过程描述了 如何读取 在 "立刻加列" 之前写入的数据,其实质是:在读取数据的过程中,"伪造" 了一个新列出来


那么如何读取 在 "立刻加列" 之后 写入的数据呢 ? 过程如下图:

MySQL 为表添加列 是怎么“立刻”完成的-爱可生


当读取 行 4 时:

  • 通过判断 数据行的头信息中的instant 标志位,可以知道该行的格式是 "新格式":该行头信息后有一个新字段 "列数"

  • 通过读取 数据行的 "列数" 字段,可以知道 该行数据中多少列有 "真实" 的数据,从而按列数读取数据


通过上图可以看到:读取 在"立刻加列" 前/后写入的数据是不同的流程


通过以上的讨论,我们可以总结 "立刻加列" 之所以高效的原因是:


  1. 在执行 "立刻加列" 时,不变更数据行的结构

  2. 读取 "旧" 数据时,"伪造" 新增的列,使结果正确

  3. 写入 "新" 数据时,使用了新的数据格式(增加了instant标志位 和 "列数" 字段),以区分新旧数据

  4. 读取 "新" 数据时,可以如实读取数据


那么 我们是否能一直 "伪造" 下去 ? "伪造" 何时会被拆穿 ?


考虑以下场景:

  1. 用 "立刻加列" 增加列 A

  2. 写入数据行 1

  3. 用 "立刻加列" 增加列 B

  4. 写入数据行 2

  5. 删除列 B

我们推测一下 "删除列 B" 的最小代价:需要修改 数据行中的instant标志位或 "列数" 字段,这至少会影响到 "立刻加列" 之后写入的数据行,成本类似于重建数据


从以上推测可知:当出现 与 "立刻加列" 操作不兼容 的 DDL 操作时,数据表需要进行重建,如下图所示:

MySQL 为表添加列 是怎么“立刻”完成的-爱可生


扩展思考题:是否能设计其他的数据格式,取代instant标志位和 "列数" 字段,使得 加列/删列 操作都能 "立刻完成" ?(提示:考虑 加列 - 删列 - 再加列 的情况)


使用限制

在了解原理之后,我们来看看 "立刻加列" 的使用限制,就很容易能理解其中的前两项:


  1. "立刻加列" 的加列位置只能在表的最后,而不能加在其他列之间
    在元数据中,只记录了 数据行 应有多少列,而没有记录 这些列 应出现的位置。所以无法实现指定列的位置

  2. "立刻加列" 不能添加主键列
    加列 不能涉及聚簇索引的变更,否则就变成了 "重建" 操作,不是 "立刻" 完成了

  3. "立刻加列"不支持压缩的表格式按照 WL 的说法:"COMPRESSED is no need to supported"(没必要支持不怎么用的格式)


总结回顾


我们总结一下上面的讨论:

  1. "立刻加列" 之所以高效的原因是:

    1. 在执行 "立刻加列" 时,不变更数据行的结构

    2. 读取 "旧" 数据时,"伪造" 新增的列,使结果正确

    3. 写入 "新" 数据时,使用了新的数据格式 (增加了 instant 标志位 和 "列数" 字段),以区分新旧数据

    4. 读取 "新" 数据时,可以如实读取数据

  2. "立刻加列" 的 "伪造" 手法,不能一直维持下去。当发生 与 "立刻加列" 操作不兼容 的 DDL 时,表数据就会发生重建


回到之前遗留的两个问题:


  • "立刻加列" 是如何工作的 ?我们已经解答了这个问题

  • 所谓 "立刻加列" 是否完全不影响业务,是否是真正的 "立刻" 完成 ?可以看到:就算是 "立刻加列",也需要变更 数据字典,那么 该上的锁还是逃不掉的。也就是说 这里的 "立刻" 指的是 "不变更数据行的结构",而并非指 "零成本地完成任务"

上一篇
分享一些对 MySQL 隔离级别的剖析
400-820-6580 13916131869
marketing@actionsky.com
上海市闵行区万源路2138号泓茂中心2号楼
产品详情
关系型数据库
AI数据库
数据库智能管理平台
数据库生态产品
行业案例
金融行业
新零售行业
制造业
通信行业
更多
公司动态
最新新闻
国产化信息
技术分享
关于我们
公司简介
公司分布
国家专利
资质认证
扫码关注公众号
© Copyright 2017, All rights reserved by: 上海爱可生信息技术股份有限公司 沪ICP备12003970号-1 | 法律声明 | 网站地图
沪公网安备 31010402003331号