执行DDL的ALTER语句增加了新的关键字INSTANT,用户可以显式地指定,MySQL也会自动选择合适的算法,因此Instant DDL对用户是透明的。

  • Instant add column
    • 当一条alter语句中同时存在不支持instant的ddl时,则无法使用
    • 只能顺序加列
    • 不支持压缩表、不支持包含全文索引的表
    • 不支持临时表,临时表只能使用copy的方式执行DDL
    • 不支持那些在数据词典表空间中创建的表
  • 修改索引类型
  • 修改ENUM/SET类型的定义
    • 存储的大小不变时
    • 向后追加成员
  • 增加或删除类型为virtual的generated column
  • RENAME TABLE操作

随着业务的发展,加字段是最常见表结构变更类型。Instant add column功能不需要修改存储层数据,更不需要重建表,只改变了存储在系统表中的表结构,其执行效率非常高。解决了以下业务上的痛点:

  • 对大表的加字段操作通常需要耗时十几个小时甚至数天的时间
  • 加字段过程中需要创建临时表,消耗大量存储资源
  • binlog复制是事务维度的,DDL会造成主备延时

在实现上,MySQL并没有在系统表中记录多个版本的schema,而是非常取巧的扩展了存储格式。在已有的info bits区域和新增的字段数量区域记录了instant column信息,instant add column之前的数据不做任何修改,之后的数据按照新格式存储。同时在系统表的private_data字段存储了instant column的默认值信息。查询时,读出的老记录只需要增加instant column默认值,新记录则按照新的存储格式进行解析,做到了新老格式的兼容。当然,这种实现方式带来的限制就是只能顺序加字段。

官方设计文档详见:。本文主要梳理了新的存储格式、DDL、查询以及插入的执行流程。

Online Add Column流程

8.0.12版本之前的MySQL在进行加列操作时,需要更新数据字典并重建表空间,所有的数据行都必须改变长度用于存放增加的数据,DDL操作运行时间很长,占用大量系统资源,更需要额外的磁盘空间(建立临时表),影响系统吞吐,而且一旦执行过程中发生crash,恢复时间也很长。

主要流程:

Instant Add Column流程

Instant add column在增加列时,实际上只是修改了schema,并没有修改原来存储在文件中的行记录,不需要执行最耗时的rebuild和apply row log过程,因此效率非常高。

在执行instant add column的过程中,MySQL会将第一次intant add column之前的字段个数以及每次加的列的默认值保存在tables系统表的se_private_data字段中。

  • dd::Table::se_private_data::instant_col: 第一次instant ADD COLUMN之前表上面的列的个数, 具体过程详见函数dd_commit_instant_table。
  • dd::Column::se_private_data::default_null: 标识instant column的默认值是否为NULL,具体过程详见函数dd_add_instant_columns。
  • dd::Column::se_private_data::default:当instant column的默认值不是NULL时存储具体的默认值,column default value需要从innodb类型byte转换成se_private_data中的char类型,具体过程详见函数dd_add_instant_columns。

载入数据字典

MySQL从系统表读取表定义时,会将instant column相关的信息载入到InnoDB的表对象dict_table_t和索引对象dict_index_t中。

  • dict_table_t::n_instant_cols: 第一次instant add column之前的非虚拟字段个数(包含系统列), 具体过程详见函数dd_fill_dict_table
  • dict_index_t::instant_cols: 用于标示是否存在Instant column,具体过程详见函数dict_index_add_to_cache_w_vcol
  • dict_index_t::n_instant_nullable:第一次instant add column之前的可为NULL的字段个数,具体过程详见函数dict_index_add_to_cache_w_vcol
  • dict_col_t::instant_default: 存储默认值及其长度,具体过程详见函数dd_fill_instant_columns

记录格式

InnoDB存储引擎支持的行格式包括REDUNDANT,COMPACT以及DYNAMIC,REDUNDANT类型的行记录了完整的元数据信息,可以自解析,但对于COMPACT和DYNAMIC类型,为了减少存储空间,其行内并不包括元数据,尤其是列的个数,因此解析记录时需要额外的元数据辅助。

以COMPACT为例,其行格式为: row_format

变长字段长度列表

COMPACT行格式的首部是一个变长字段长度列表,这个列表是按照字段的顺序逆序放置的。如果字段的字义长度大于255个字节,或者字段的数据类型为BLOB的,则用2个字节来存储该字段的长度;如果定义长度小于128个字节,或者小于256个字节,但类型不是BLOB类型的,则用一个字节来存储该字段的长度,除此之外都用2个字节来存储。

NULL字段标志位

变长字段长度列表之后是NULL字段标志位,这个标志位用于记录中哪些字段的值是null,只存储nullable属性的字段,不会存储属性为not nulll的字段。每一bit都表示一个nullable的字段的null属性,如果为null则设置为1,这个bit vector也是按照字段的顺序逆序放置的,整个标志位长度取决于记录中nullable字段的个数,而是以8为单位,满8个null字段就多1个字节,不满8个也占用1个字节,高位用0补齐。

记录头信息

记录头信息最开始的4个bit组成了info bits, 目前只使用了两个bit,具体含义如下:

  • 如果没有执行过instant add column操作,则表的行记录格式保持不变。
  • 如果执行过instant add column操作,则所有新的记录都会设置一个特殊的标记,同时在记录内存储字段的个数。

这个特殊的INSTANT_FLAG使用了info bits中的一个bit位,如果记录是第一次instant add column之后插入的,该flag被设置为1,且记录中会使用1或2个字节来存储字段的个数,如果字段个数小于等于127,则使用1个字节存储,否则使用2个字节存储。 相关代码:

  1. uint8_t rec_get_n_fields_length(ulint n_fields) {
  2. return (n_fields > REC_N_FIELDS_ONE_BYTE_MAX ? 2 : 1);
  3. }
  4. // 设置字段数量
  5. uint8_t rec_set_n_fields(rec_t *rec, ulint n_fields) {
  6. // 指向记录头信息的前一个字节
  7. byte *ptr = rec - (REC_N_NEW_EXTRA_BYTES + 1);
  8. ut_ad(n_fields < REC_MAX_N_FIELDS);
  9. // 如果字段数量小于或等于127
  10. if (n_fields <= REC_N_FIELDS_ONE_BYTE_MAX) {
  11. // 在当前位置存储字段数量
  12. *ptr = static_cast<byte>(n_fields);
  13. // 存储字段数量的字节数是1
  14. return (1);
  15. }
  16. // 如果字段数量大于127,向前移动一个字节
  17. --ptr;
  18. // 第一个字节记录低8位数据
  19. *ptr++ = static_cast<byte>(n_fields & 0xFF);
  20. // 第二个字节记录高8位数据
  21. *ptr = static_cast<byte>(n_fields >> 8);
  22. ut_ad((*ptr & 0x80) == 0);
  23. *ptr |= REC_N_FIELDS_TWO_BYTES_FLAG;
  24. // 存储字段数量的字节数是2
  25. return (2);
  26. }

表结构和初始化数据

idb文件解析

  1. $ hexdump -C -v t1.ibd > t1.txt
  2. 00010070 73 75 70 72 65 6d 75 6d 03 0a 02 01 00 00 00 10 |supremum........|
  3. 00010080 00 29 80 00 00 01 00 00 00 00 07 d8 9e 00 00 00 |.)..............|
  4. 00010090 94 01 10 61 61 62 61 62 20 20 20 20 20 20 20 20 |...aabab |
  5. 000100a0 63 63 63 03 01 06 00 00 18 00 1f 80 00 00 02 00 |ccc.............|
  6. 000100b0 00 00 00 07 d9 9f 00 00 00 94 01 10 62 64 64 64 |............bddd|
  • 第一行记录从0x00010078开始
  • 第二行记录从0x000100a3开始

执行instant add column

idb文件解析

  1. $ hexdump -C -v t1.ibd > t1.txt
  2. 00010070 73 75 70 72 65 6d 75 6d 03 0a 02 01 00 00 00 10 |supremum........|
  3. 00010080 00 29 80 00 00 01 00 00 00 00 07 d8 9e 00 00 00 |.)..............|
  4. 00010090 94 01 10 61 61 62 61 62 20 20 20 20 20 20 20 20 |...aabab |
  5. 000100a0 63 63 63 03 01 06 00 00 18 00 1f 80 00 00 02 00 |ccc.............|
  6. 000100b0 00 00 00 07 d9 9f 00 00 00 94 01 10 62 64 64 64 |............bddd|
  7. 000100c0 04 03 01 06 08 80 00 20 ff a6 80 00 00 03 00 00 |....... ........|
  8. 000100d0 00 00 07 e7 a0 00 00 00 95 01 10 63 65 65 65 65 |...........ceeee|
  9. 000100e0 65 65 65 00 00 00 00 00 00 00 00 00 00 00 00 00 |eee.............|
  • 前两行记录没有变化

查询

查询的流程没有变化,关键点在于如何准确地解析记录,对于没有存储在记录中的instant column, 直接填默认值即可,关键函数是rec_init_null_and_len_comp。 主要流程:

插入

执行instant add column后,老数据的格式没有变化,新插入的数据按照新格式存储,关键函数是rec_convert_dtuple_to_rec_comp,该函数将MySQL逻辑记录转换为COMPACT格式的物理记录。此外,函数rec_set_instant_flag_new在记录的Info bits字段设置REC_INFO_INSTANT_FLAG,表示这个记录是instant add column之后创建的。

  1. bool rec_convert_dtuple_to_rec_comp(rec_t *rec, const dict_index_t *index,
  2. const dfield_t *fields, ulint n_fields,
  3. const dtuple_t *v_entry, ulint status,
  4. bool temp) {
  5. const dfield_t *field;
  6. const dtype_t *type;
  7. byte *end;
  8. byte *nulls;
  9. byte *lens = NULL;
  10. ulint len;
  11. ulint i;
  12. ulint n_node_ptr_field;
  13. ulint fixed_len;
  14. ulint null_mask = 1;
  15. ulint n_null = 0;
  16. ulint num_v = v_entry ? dtuple_get_n_v_fields(v_entry) : 0;
  17. bool instant = false;
  18. ut_ad(temp || dict_table_is_comp(index->table));
  19. if (n_fields != 0) {
  20. // 获得nullable字段个数
  21. n_null = index->has_instant_cols()
  22. ? index->get_n_nullable_before(static_cast<uint32_t>(n_fields))
  23. : index->n_nullable;
  24. }
  25. if (temp) {
  26. ut_ad(status == REC_STATUS_ORDINARY);
  27. ut_ad(n_fields <= dict_index_get_n_fields(index));
  28. n_node_ptr_field = ULINT_UNDEFINED;
  29. nulls = rec - 1;
  30. /* No need to do adjust fixed_len=0. We only
  31. need to adjust it for ROW_FORMAT=REDUNDANT. */
  32. temp = false;
  33. }
  34. } else {
  35. ut_ad(v_entry == NULL);
  36. ut_ad(num_v == 0);
  37. // 指向指向记录头信息的前一个字节
  38. nulls = rec - (REC_N_NEW_EXTRA_BYTES + 1);
  39. switch (UNIV_EXPECT(status, REC_STATUS_ORDINARY)) {
  40. case REC_STATUS_ORDINARY:
  41. ut_ad(n_fields <= dict_index_get_n_fields(index));
  42. n_node_ptr_field = ULINT_UNDEFINED;
  43. // 如果存在instant column,那么还存在字段个数信息,调用rec_set_n_fields设置
  44. // 字段数量,并返回存储字节数, 如果字段数量不大于127,存储长度为1字节,否则为2字节
  45. if (index->has_instant_cols()) {
  46. uint32_t n_fields_len;
  47. n_fields_len = rec_set_n_fields(rec, n_fields);
  48. // nulls指向存储字段数量信息的前一个字节,也就是null标志位最后一个字节开始的位置
  49. nulls -= n_fields_len;
  50. instant = true;
  51. }
  52. break;
  53. case REC_STATUS_NODE_PTR:
  54. ut_ad(n_fields ==
  55. static_cast<ulint>(
  56. dict_index_get_n_unique_in_tree_nonleaf(index) + 1));
  57. n_node_ptr_field = n_fields - 1;
  58. n_null = index->n_instant_nullable;
  59. break;
  60. case REC_STATUS_INFIMUM:
  61. case REC_STATUS_SUPREMUM:
  62. ut_ad(n_fields == 1);
  63. n_node_ptr_field = ULINT_UNDEFINED;
  64. break;
  65. default:
  66. ut_error;
  67. return (instant);
  68. }
  69. }
  70. end = rec;
  71. if (n_fields != 0) {
  72. // 指向变长字段长度列表最后一个字节开始的位置
  73. lens = nulls - UT_BITS_IN_BYTES(n_null);
  74. /* clear the SQL-null flags */
  75. memset(lens + 1, 0, nulls - lens);
  76. }
  77. /* Store the data and the offsets */
  78. // 遍历所有字段
  79. for (i = 0; i < n_fields; i++) {
  80. const dict_field_t *ifield;
  81. dict_col_t *col = NULL;
  82. field = &fields[i];
  83. type = dfield_get_type(field);
  84. len = dfield_get_len(field);
  85. if (UNIV_UNLIKELY(i == n_node_ptr_field)) {
  86. ut_ad(dtype_get_prtype(type) & DATA_NOT_NULL);
  87. ut_ad(len == REC_NODE_PTR_SIZE);
  88. memcpy(end, dfield_get_data(field), len);
  89. end += REC_NODE_PTR_SIZE;
  90. break;
  91. }
  92. // 如果不是not null类型的字段
  93. if (!(dtype_get_prtype(type) & DATA_NOT_NULL)) {
  94. /* nullable field */
  95. ut_ad(n_null--);
  96. // 如果写满8个,则offset向左移1位,并将null_mask置为1
  97. if (UNIV_UNLIKELY(!(byte)null_mask)) {
  98. nulls--;
  99. }
  100. ut_ad(*nulls < null_mask);
  101. // 如果字段是null
  102. if (dfield_is_null(field)) {
  103. // 将null标志位设为1
  104. *nulls |= null_mask;
  105. // 向前移1位
  106. null_mask <<= 1;
  107. continue;
  108. }
  109. null_mask <<= 1;
  110. }
  111. /* only nullable fields can be null */
  112. ut_ad(!dfield_is_null(field));
  113. ifield = index->get_field(i);
  114. fixed_len = ifield->fixed_len;
  115. col = ifield->col;
  116. if (temp && fixed_len && !col->get_fixed_size(temp)) {
  117. fixed_len = 0;
  118. }
  119. /* If the maximum length of a variable-length field
  120. is up to 255 bytes, the actual length is always stored
  121. in one byte. If the maximum length is more than 255
  122. bytes, the actual length is stored in one byte for
  123. 0..127. The length will be encoded in two bytes when
  124. it is 128 or more, or when the field is stored externally. */
  125. if (fixed_len) {
  126. #ifdef UNIV_DEBUG
  127. ulint mbminlen = DATA_MBMINLEN(col->mbminmaxlen);
  128. ulint mbmaxlen = DATA_MBMAXLEN(col->mbminmaxlen);
  129. ut_ad(len <= fixed_len);
  130. ut_ad(!mbmaxlen || len >= mbminlen * (fixed_len / mbmaxlen));
  131. ut_ad(!dfield_is_ext(field));
  132. #endif /* UNIV_DEBUG */
  133. } else if (dfield_is_ext(field)) {
  134. ut_ad(DATA_BIG_COL(col));
  135. ut_ad(len <= REC_ANTELOPE_MAX_INDEX_COL_LEN + BTR_EXTERN_FIELD_REF_SIZE);
  136. *lens-- = (byte)(len >> 8) | 0xc0;
  137. *lens-- = (byte)len;
  138. } else {
  139. /* DATA_POINT would have a fixed_len */
  140. ut_ad(dtype_get_mtype(type) != DATA_POINT);
  141. #ifndef UNIV_HOTBACKUP
  142. ut_ad(len <= dtype_get_len(type) ||
  143. DATA_LARGE_MTYPE(dtype_get_mtype(type)) ||
  144. !strcmp(index->name, FTS_INDEX_TABLE_IND_NAME));
  145. #endif /* !UNIV_HOTBACKUP */
  146. if (len < 128 ||
  147. !DATA_BIG_LEN_MTYPE(dtype_get_len(type), dtype_get_mtype(type))) {
  148. *lens-- = (byte)len;
  149. } else {
  150. ut_ad(len < 16384);
  151. // 设置变长字段长度信息
  152. *lens-- = (byte)(len >> 8) | 0x80;
  153. *lens-- = (byte)len;
  154. }
  155. }
  156. if (len > 0) memcpy(end, dfield_get_data(field), len);
  157. end += len;
  158. }
  159. if (!num_v) {
  160. return (instant);
  161. }
  162. /* reserve 2 bytes for writing length */
  163. byte *ptr = end;
  164. ptr += 2;
  165. ......
  166. mach_write_to_2(end, ptr - end);
  167. return (instant);

MySQL的instant add column功能极大地提高了增加字段的效率,执行过程中不需要修改存储中的数据,只改变了存储在系统表中的表结构。期待MySQL能支持更多更实用的instant DDL类型,例如任意顺序加字段、删字段、修改字段类型等,这可能需要引入更复杂的多版本schema技术,设置将更多的schema信息下沉到存储层,实现难度无疑会大大增加。