引言

早期的MySQL仅支持copy模式的DDL。在MySQL 5.5中，引入了inplace算法，可以将部分DDL操作交给引擎层进行处理，但是在进行DDL期间，依旧会阻塞DML操作。在5.6中，部分inplace DDL操作可以采用online算法。该算法允许用户在进行DDL操作过程中，并行的执行写入操作。有关上述三种DDL的差异及主要特点，可以参照文末的扩展阅读部分。

以add column操作为例，下图给出了online算法进行DDL的主要流程。

img

可以看到，在online DDL过程中，使用row log 记录并行的写入请求，等待DDL操作完成后，再将该部分写入请求应用在最新的表中。通过这种方式，能够减少DDL操作对业务影响。本文主要聚焦于row log的格式、生成和应用的相关函数解析。以下分析均基于MySQL-8.0.18版本。

一. row log 格式

根据不同的DML操作，row log分为三种类型，分别是ROW_T_INSERT、ROW_T_UPDATE和ROW_T_DELETE，分别对应insert，update和delete操作。一条row log记录通常由如下四部分组成。

  1. Part 1: opt type
  2.     | 1 byte: 记录row log的操作类型。也即ROW_T_INSERT、ROW_T_UPDATE、ROW_T_DELETE
  3. Part 2: old pk (optional)
  4.     | 1 byte: extral size，也即old pk对应的rec的extral部分长度。
  5.     | extral size byte: 存储old pk对应rec的extral数据
  6.     | 不定长: 存储old pk对应rec的 field 部分数据。
  7. Part 3: record data (optional)
  8.     | 1-2 bytes：extral size 记录当前rec对应的extral数据长度
  9.     | extral size: 待写入rec的extral部分数据
  10.     | 不定长：待写入rec的field部分数据。
  11. part 4: virtual column data (optional)
  12.     | 2 bytes: 虚拟列部分总的数据长度
  13.     | 不定长：虚拟列对应的field数据。

其中，不同类型的DML操作，对应所记录的row log内容也有一定差别。具体表现为：

  • insert 类型

insert 类型的row log日志，在插入新表时，借助于col map即可映射到新表，无需记录旧表的主键信息。因此该类型row log仅包含标识符、record data和虚拟列信息（如有）；

  • update类型

与insert操作相比，update类型的row log日志中，可能会包含old pk信息。这是因为如果新旧表之间主键信息发生了变化，则需要借助旧表的old pk信息在新表上进行定位。其余格式与insert 保持一致。

  • delete 类型

delete 类型的row log在应用时，仅需在新表中将对应rec进行打标。因此，该类型仅需要记录old pk数据即可。不存在rec data和virtual field部分。

二. row log生成

在MySQL内部，与row log生成相关的函数可以分为主键索引和二级索引两大类。

1. 表相关的DML操作。

对表数据的操作可以分为INSERT、UPDATE和DELETE三类，分别由 row_log_table_insert() row_log_table_update(),row_log_table_delete()记录。其中由于insert 与update对应的row log格式相似，因此在内部统一调用函数row_log_table_low()进行记录。

2. 二级索引相关DML操作。

在innodb引擎中，对二级索引的update操作是通过delete+insert 方式进行的。因此对于二级索引，row log只有insert和update两种类型。统一由函数row_log_online_op()进行记录。

三. row log 应用

row log的应用发生在online DDL的commit阶段。在该阶段，会对所有在DDL执行阶段记录的row log进行回放。回放函数为row_log_table_apply_op()。该函数根据row log的操作类型，对row log进行解析处理。row_log_table_apply_op()函数功能可以抽象概括如下：

  1. const mrec_t *row_log_table_apply_op(
  2. {
  3.     ...
  4.   /* Load row log type. */
  5.   switch (row_log_type) {
  6.     default:
  7.       ut_ad(0);
  8.       *error = DB_CORRUPTION;
  9.       return (NULL);
  10.     case ROW_T_INSERT:
  11.       row_log_table_apply_insert();
  12.       break;
  13.     case ROW_T_DELETE:
  14.       *error = row_log_table_apply_delete();
  15.       break;
  16.     case ROW_T_UPDATE:
  17.         *error = row_log_table_apply_update();
  18.       break;
  19.  }
  20.     ....
  21.  return ;
  22. }

四. row log中的record data

1. temp格式

读者在阅读row log代码时，会注意到，在这一过程中会出现temp格式的record。这是官方为了节约row log大小而引入的格式。以compact格式为例，其格式如下所示：

img

其中，上文提到的extral部分指代的是变长字段长度列表和NULL字段标志位，并不包含记录头信息。也即与完整的compact、redunment格式相比，temp格式胜过省略记录头信息，降低了row log的大小。

针对此类格式的record，官方也提供了相关的接口函数。其中rec_get_converted_size_temp()可以用于计算temp格式rec的大小。rec_convert_dtuple_to_temp可以将tuple转化为temp格式的rec。对应的，rec_init_offsets_temp()和rec_init_null_and_len_temp()则用于对temp格式的rec进行解析。

事实上，temp格式的record不仅用于row log中，还被用于sort buffer中, 减少sort buffer的大小。

2. instant add column对row log格式的修改

MySQL在8.0版本引入了instant add column功能，该功能可以通过仅修改元数据的方式，实现加列操作。该功能是通过对列格式进行修改而实现的。以compact格式为例，修改后的列格式为：

img

可以看出，其通过在record的记录头中，添加了一个INSTANT_FLAG标志位，来表示该记录中是否存在字段数量字段。借助该信息，来正确的解析instant add column前后的record数据。

同样的，对于执行过instant add column操作的表，在row log中记录record数据时，也同样需要记录字段数量信息。为了解决这一问题，MySQL对row log进行了扩展。在compact格式的reord，在生成row log时，如果当前表进行过instant add column操作，则会额外记录record的info bits信息。对应的，在调用函数rec_init_null_and_len_temp()用于解析时，也使用index中的instant标志位，辅助判断当前的temp格式的rec中是否存在info bits 信息。若存在该信息，则使用该信息辅助用于record解析。

结语

本文对row log格式以及相关的生成和应用函数做了简单介绍。希望能够帮助读者更好的了解row log的作用原理。受限于时间和笔者能力水平，文章内容可能存在错误，请大家批评指正。

扩展阅读

  1. 《MySQL · 源码阅读 · 白话Online DDL》
  2. 《MySQL · 引擎特性 · 8.0 Instant Add Column功能解析》
  3. 《MySQL · 源码阅读 · 创建二级索引》