`InnoDB`的`Online DDL`：`ALGORITHM=INPLACE`和`INSTANT`的`底层`实现与`数据`拷贝`机制`。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好的，下面开始本次关于InnoDB Online DDL中ALGORITHM=INPLACE和INSTANT的底层实现与数据拷贝机制的讲座。

InnoDB Online DDL: ALGORITHM=INPLACE vs. INSTANT – 底层机制深度剖析

大家好，今天我们来深入探讨InnoDB中Online DDL（在线数据定义语言）的两种关键算法：ALGORITHM=INPLACE和ALGORITHM=INSTANT。了解它们的底层实现和数据拷贝机制，对于我们更好地使用和优化数据库至关重要。

1. Online DDL 概述

首先，简单回顾一下Online DDL的概念。在传统DDL操作中，数据库通常需要锁定整个表，阻止读写操作，这会导致服务中断。 Online DDL的目标是在执行DDL操作的同时，尽可能减少甚至消除锁定，允许并发的读写操作，从而减少对应用程序的影响。

InnoDB通过多种算法实现了Online DDL，其中最重要的是ALGORITHM=INPLACE和ALGORITHM=INSTANT。如果没有指定ALGORITHM，InnoDB会根据操作类型和配置自动选择合适的算法。

2. ALGORITHM=INPLACE

ALGORITHM=INPLACE表示DDL操作在原始表上直接进行，不需要创建临时表。然而，这并不意味着完全没有锁定或数据拷贝。 INPLACE操作通常涉及以下几个阶段：

准备阶段： 初始化DDL操作，获取必要的元数据锁。
执行阶段： 这是最关键的阶段，根据DDL操作的类型，可能涉及数据拷贝，索引重建等。
提交阶段： 提交DDL操作，更新元数据。

2.1 INPLACE 的数据拷贝机制

INPLACE算法是否涉及数据拷贝取决于具体的DDL操作。有些操作只需要修改元数据，不需要拷贝数据，例如：

修改列的默认值 (如果默认值不影响现有行)
修改列的注释
重命名表

但是，很多常见的DDL操作确实需要拷贝数据，例如：

修改列的数据类型（例如，INT -> BIGINT， VARCHAR(10) -> VARCHAR(20)）
添加或删除列（即使是NULLABLE列）
更改列的排序规则
修改主键

当需要拷贝数据时，InnoDB会以行格式转换的方式进行。它会逐行读取原始表的数据，按照新的表结构进行转换，然后写入到原始表。这个过程被称为rebuild table 或者copy to tmp table。需要注意的是，尽管名为INPLACE，但实际上 InnoDB 内部会创建一些临时段(temporary segment)来辅助完成数据转换和重写操作。

2.2 INPLACE 的锁定机制

INPLACE算法在执行期间通常会使用共享锁或者排他锁，防止数据不一致。具体锁的类型和范围取决于DDL操作的类型和LOCK子句。 LOCK子句可以指定在DDL操作期间允许的并发级别，例如：

LOCK=NONE: 允许并发读写操作，但可能导致DDL操作花费更长时间。
LOCK=SHARED: 允许并发读操作，但阻止写操作。
LOCK=EXCLUSIVE: 阻止所有并发读写操作，相当于传统的DDL操作。
LOCK=DEFAULT: InnoDB根据操作类型自动选择合适的锁级别。

2.3 INPLACE 的底层实现

让我们看一个具体的例子，假设我们要修改表users的email列的数据类型，从VARCHAR(50)改为VARCHAR(100):

ALTER TABLE users MODIFY COLUMN email VARCHAR(100) NOT NULL, ALGORITHM=INPLACE, LOCK=NONE;

这个操作的底层实现大致如下：

初始化: InnoDB获取users表的元数据锁，检查操作的合法性。
创建临时段: InnoDB 创建一个临时段，用于存储中间数据。这个临时段不是一个完整的临时表，而是用于辅助数据转换和重写操作。
行格式转换: InnoDB逐行读取users表的数据，并将email列的数据转换为VARCHAR(100)类型。
重写数据: 将转换后的数据写回到users表。由于我们指定了LOCK=NONE，因此在重写数据的过程中，允许并发的读写操作。 InnoDB使用row log记录在重写数据期间发生的修改，并在重写完成后将这些修改应用到新的数据上，保证数据一致性。
清理临时段: 删除临时段。
更新元数据: 更新users表的元数据，包括email列的数据类型。
提交: 提交DDL操作，释放元数据锁。

2.4 INPLACE 的代码示例 (伪代码)

以下是一个简化的伪代码，展示了INPLACE算法中数据拷贝的核心逻辑：

def inplace_alter_column(table_name, column_name, new_data_type):
    """
    模拟 INPLACE 算法修改列的数据类型
    """
    table_metadata = get_table_metadata(table_name)
    original_rows = get_all_rows(table_name)

    # 创建临时段 (实际上不是一个表，而是用于辅助数据转换)
    temp_segment = create_temp_segment()

    # 逐行处理数据
    for row in original_rows:
        original_value = row[column_name]
        # 数据类型转换
        new_value = convert_data_type(original_value, new_data_type)
        # 创建新的行
        new_row = row.copy() #复制所有字段
        new_row[column_name] = new_value
        # 将新行写入临时段
        write_row_to_temp_segment(temp_segment, new_row)

        # 在重写期间，如果发生对这一行的修改，记录到row log
        if row_modified_during_rewrite(table_name, row):
            log_row_modification(table_name, row)

    #清空原表数据
    truncate_table(table_name)

    # 将临时段的数据写回原表
    all_rows_from_temp_segment = get_all_rows_from_temp_segment(temp_segment)
    for row in all_rows_from_temp_segment:
        write_row_to_table(table_name, row)

    # 应用重写期间的修改
    apply_row_modifications(table_name)

    # 清理临时段
    drop_temp_segment(temp_segment)

    # 更新元数据
    update_table_metadata(table_name, column_name, new_data_type)

    print(f"Table {table_name} column {column_name} data type changed to {new_data_type} INPLACE.")

2.5 INPLACE 的限制

INPLACE算法虽然避免了创建完整的临时表，但仍然有一些限制：

性能: 对于大型表，数据拷贝仍然是一个耗时的过程。
磁盘空间: 虽然不需要完整的临时表，但需要额外的磁盘空间来存储中间数据和row log。
某些操作不支持: 并非所有的DDL操作都支持ALGORITHM=INPLACE。例如，修改表的字符集通常需要ALGORITHM=COPY。

3. ALGORITHM=INSTANT

ALGORITHM=INSTANT是InnoDB中最高效的Online DDL算法。它避免了数据拷贝和大部分锁定，几乎可以瞬间完成DDL操作。然而，INSTANT算法只适用于非常有限的操作，通常是只修改元数据的操作，不会影响现有数据。

3.1 INSTANT 适用的 DDL 操作

以下是一些典型的适用ALGORITHM=INSTANT的DDL操作：

添加一个NULLABLE的列，并且带有DEFAULT值： InnoDB只需要修改元数据，将新列添加到表的定义中，并在读取数据时，如果该列的值为NULL，则返回DEFAULT值。不需要修改现有的数据行。
删除一个NULLABLE的列： InnoDB只需要修改元数据，将该列从表的定义中移除。不需要修改现有的数据行。
重命名表： InnoDB只需要修改元数据，更新表的名称。
修改表的注释： InnoDB只需要修改元数据，更新表的注释。

3.2 INSTANT 的底层实现

INSTANT算法的底层实现非常简单，它主要涉及以下步骤：

获取元数据锁： InnoDB获取表的元数据锁，防止并发的DDL操作。这个锁通常是短暂的。
修改元数据： 根据DDL操作的类型，修改表的元数据。
提交： 提交DDL操作，释放元数据锁。

由于不需要拷贝数据，也不需要长时间锁定表，因此INSTANT算法非常高效。

3.3 INSTANT 的代码示例 (伪代码)

以下是一个简化的伪代码，展示了INSTANT算法添加一个NULLABLE列的核心逻辑：

def instant_add_nullable_column(table_name, column_name, data_type, default_value):
    """
    模拟 INSTANT 算法添加一个 NULLABLE 列
    """
    table_metadata = get_table_metadata(table_name)

    # 修改元数据，添加新列
    table_metadata['columns'][column_name] = {
        'data_type': data_type,
        'is_nullable': True,
        'default_value': default_value
    }

    # 更新表的元数据
    update_table_metadata(table_name, table_metadata)

    print(f"Table {table_name} column {column_name} added INSTANTLY.")

def get_column_value(table_name, row, column_name):
    """
    获取列的值，如果列不存在，则返回默认值
    """
    table_metadata = get_table_metadata(table_name)
    if column_name in row:
        return row[column_name]
    elif column_name in table_metadata['columns']:
        column_info = table_metadata['columns'][column_name]
        if column_info['is_nullable']:
            return column_info['default_value']
        else:
            raise Exception("Column does not exist and is not nullable.")
    else:
        raise Exception("Column does not exist.")

在读取数据时，数据库会检查请求的列是否存在于存储的行数据中。如果不存在，并且该列定义为可空（NULLABLE）且具有默认值（DEFAULT），则数据库会返回该默认值。这种机制使得添加新列的操作可以立即完成，无需修改现有的数据行。

3.4 INSTANT 的限制

INSTANT算法的限制非常明显：它只适用于非常有限的DDL操作。对于需要修改现有数据的DDL操作，INSTANT算法是不适用的。

4. 算法选择和最佳实践

在选择DDL算法时，需要综合考虑以下因素：

DDL操作的类型： 不同的DDL操作支持不同的算法。
表的大小： 对于大型表，INPLACE算法的数据拷贝可能需要很长时间，而INSTANT算法则可以快速完成。
并发需求： LOCK子句可以控制DDL操作期间的并发级别。
磁盘空间： INPLACE算法可能需要额外的磁盘空间来存储中间数据和row log。

一般来说，最佳实践是：

尽可能使用ALGORITHM=INSTANT，因为它最快，对应用程序的影响最小。
如果ALGORITHM=INSTANT不适用，则考虑使用ALGORITHM=INPLACE，并根据需要调整LOCK子句。
避免使用ALGORITHM=COPY，因为它需要创建完整的临时表，效率最低。

5. 总结：不同算法适用于不同场景，权衡利弊

ALGORITHM=INPLACE通过行格式转换和临时段来避免创建完整的临时表，但仍然涉及数据拷贝和锁定，适用于大多数DDL操作。 ALGORITHM=INSTANT只修改元数据，避免了数据拷贝和锁定，适用于添加/删除NULLABLE列等操作。选择合适的算法需要权衡性能、并发和磁盘空间等因素。

希望本次讲座能够帮助大家更好地理解InnoDB Online DDL的ALGORITHM=INPLACE和ALGORITHM=INSTANT算法的底层实现和数据拷贝机制。

发表回复 取消回复

发表回复取消回复