【华为云MySQL技术专栏】TaurusDB表级恢复中的外键处理优化

1. 背景

对于云上客户而言，表级时间点恢复（PITR）功能能够快速恢复被误删除的表，从而有效保障业务的连续性。然而，在进行表级恢复时，外键关系的恢复是一个极为复杂的问题。

由于外键约束要求相关表之间必须保持参照完整性，因此在恢复带外键的表时，必须特别关注表与表之间的依赖关系。如果恢复顺序错误或外键关系失效，将直接导致数据错误，影响整个恢复流程的顺利进行。

本文立足于华为云TaurusDB，将详细介绍在表级时间点恢复场景下，外键关联表的恢复方案。通过深入分析每种方案的优缺点，并进行性能对比，最终给出适用于TaurusDB 外键关联表的恢复实现方式。

2. TaurusDB恢复外键关联表的问题分析

以订单系统为例，orders 表通过外键关系依赖于 customers 表，其表结构定义如下：

CREATE TABLE customers (

customer_id INT PRIMARY KEY,

customer_name VARCHAR(100) NOT NULL

);

CREATE TABLE orders (

order_id INT PRIMARY KEY,

customer_id INT,

CONSTRAINT fk_customer_order FOREIGN KEY (customer_id) REFERENCES customers(customer_id)

);

在进行表级时间点恢复时，首先将数据通过 PITR恢复到临时实例，之后对表进行重命名，再使用 mydumper 将表数据导出到本地，最后通过 myloader 将数据导入回源实例。

在此过程中，子表 orders 会被重命名为 orders_new，父表 customers 会被重命名为 customers_new。

然而，外键约束并不会自动更新，orders_new表中定义的外键仍然依赖于原始的 customers 表，而不是重命名后的 customers_new 表。

为了保证外键的参照完整性，这一恢复流程带来了以下技术挑战：

第一，恢复顺序的复杂性

表与表之间的外键关系决定了恢复的顺序，错误的恢复顺序可能导致外键约束失败，影响数据恢复的完整性。

对于上述订单系统为例，表级恢复时存在以下几种情况：

情况一：仅恢复父表 customers 表

由于在临时实例中已对 customers 表进行了重命名（如 customers_new），在导入回源实例时，子表 orders 表仍然会依赖已存在的原始 customers 表，而不是新导入的 customers_new 表。因此，不会出现外键约束冲突的问题。

情况二：仅恢复子表orders表

• 保留原有外键定义

如果临时实例中不对子表的外键定义进行修改，那么在导入回源实例时，创建表的 schema 时会因同名外键已存在，导致“duplicate foreign key constraint name”（外键名重复）的错误，从而恢复失败。

• 重命名外键

由于 TaurusDB 并未提供直接重命名外键的功能，因此只能先删除旧外键，再重新创建新的外键。例如，对临时实例中的 orders_new 表，删除旧外键后添加新外键： CONSTRAINT fk_customer_order_new FOREIGN KEY (customer_id) REFERENCES customers(customer_id)。这样做，可以在将数据导入回源实例时，避免外键名重复的问题。

但这种方法也存在一些潜在风险。由于 orders_new 表依赖于已存在的 customers 表，而 customers 表的数据可能在恢复过程中已经发生更新，这可能导致 orders_new 表依赖的数据与恢复时刻的数据不一致，从而引发外键约束检查失败。

此外，删除和重新创建外键的操作对性能影响较大，尤其是在表数据量较大时，会显著延长表级恢复时间。

情况三：同时恢复父表 customers 表和子表 orders 表

在临时实例上重新定义外键约束，CONSTRAINT fk_customer_order_new FOREIGN KEY (customer_id) REFERENCES customers_new(customer_id)，即 orders_new 表的外键约束依赖于新的 customers_new 表。此时，恢复顺序变得尤为关键，必须先恢复父表，再恢复子表。如果父表尚未恢复完成时尝试恢复子表，外键约束可能会阻止子表数据的插入，导致恢复失败。

情况四：更复杂的外键依赖关系

（1）多层嵌套的外键结构，例如，表 A → 表 B → 表 C。在这种情况下，必须按照依赖顺序依次恢复表，即先恢复表 A，再恢复表 B，最后恢复表 C。

（2）循环依赖的外键结构，例如，表 A → 表 B → 表 C → 表 A，此时，传统的顺序恢复方法将失效，需要通过临时表或其他特殊手段来解决。

由此可见，在恢复过程中，父表和子表的恢复顺序至关重要。根据外键依赖关系图，被引用表（父表）必须先于引用表（子表）恢复。如果恢复顺序错误，可能会导致外键约束冲突，进而影响恢复的完整性和正确性。

第二，数据一致性风险

在表级时间点恢复过程中，将临时实例的表数据导入源实例时，可能会引发数据不一致的问题，具体表现如下：

（1） 孤立的子表记录。

如果子表的外键指向的父表数据在源实例中已被删除、更新，或者尚未恢复完成，而子表中的外键约束未设置为 CASCADE 或 SET NULL，则子表中可能会出现孤立的记录（即外键字段的值在父表中不存在）。这种孤立的记录会导致数据不一致，进而影响数据完整性和业务逻辑。

（2） 级联删除问题。

如果外键约束设置为 ON DELETE CASCADE，当父表中的记录被删除时，子表中相关的记录也会被自动删除。在这种情况下，如果父表未恢复，子表中可能已经丢失了与父表记录相关的重要数据，从而导致数据丢失和数据不一致。

第三，性能影响

外键约束验证在恢复过程中会显著增加计算负担，尤其是在数据量较大时，这会大幅降低恢复速度。具体表现如下：

（1）外键验证开销。

在恢复子表数据时，myloader 插入数据之前，数据库需要检查外键值是否存在于父表中。如果父表中没有相应的记录，插入或更新操作将失败。当父表数据量较大时，频繁的查询操作会显著增加表级恢复的复杂性和耗时。

（2）级联操作的额外开销。

如果外键约束定义了级联操作（如 ON DELETE CASCADE 或 ON UPDATE CASCADE），恢复时需要处理这些级联操作，这将增加额外的 CPU 负载和 I/O 开销，从而延长恢复时间。

3. 支持外键约束表恢复的解决方案

通过前文的分析，我们发现，一旦涉及外键依赖的子表，恢复过程就会变得复杂，处理不当会直接导致恢复失败或数据不一致。因此，本章节将针对这些问题，提出几种支持含外键表恢复的方案。

3.1 临时禁用外键约束检查

在恢复过程中，临时禁用外键约束检查。通过在恢复时禁用外键约束，可以提高恢复速度，避免外键验证对恢复过程的影响。恢复完成后，再重新启用外键约束并进行一致性检查。

实现方式：

（1）在表级恢复前禁用外键约束，SET FOREIGN_KEY_CHECKS = 0;

（2）执行表级恢复操作；

（3）恢复完成后重新启用外键约束， SET FOREIGN_KEY_CHECKS = 1;

（4）运行数据一致性检查，确保数据完整性。

SELECT * FROM child_table c LEFT JOIN 
    parent_table p ON c.parent_id = p.id WHERE 
    p.id IS NULL;

该SQL会查询子表中存在，但父表中找不到对应记录外键值的数据。可以根据此结果进行修复，确保数据的一致性。

优势：

恢复速度快：禁用外键约束检查可以显著提高恢复速度，特别是对于大数据量的表。

操作简便：通过临时禁用外键约束，避免了恢复过程中复杂的外键验证，操作简单。

缺点：

数据一致性风险：禁用外键约束期间，如果插入了不符合约束的数据，会导致数据不一致，再重新启用外键约束时可能会报错。

后续一致性校验：恢复完成后，需要重新启用外键约束并执行一致性检查，这可能会出现数据不一致的情况，导致额外的修复工作。

3.2 串行恢复

根据外键之间的依赖关系，按正确的顺序恢复表，确保恢复顺序正确，避免外键约束失效。

实现方式：

（1）检查要恢复的表中是否有外键依赖关系，并确认父表子表依赖顺序。

SELECT
    TABLE_NAME AS child_table,
    COLUMN_NAME AS child_column,
    REFERENCED_TABLE_NAME AS parent_table,
    REFERENCED_COLUMN_NAME AS parent_column
FROM
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE
    REFERENCED_TABLE_NAME IS NOT NULL;

该查询会返回所有表中的外键约束，列出每个外键关联的子表和父表及其对应的列。通过对表按照依赖关系进行排序，便可确定表的恢复顺序。

（2）按依赖顺序导入：通过先执行 myloader --regex '^(parent_table)$' 后执行 myloader --regex '^(child_table)$' 来指定父表先导入。

优点：

参照完整性：按顺序恢复表，确保外键约束得以维护。

缺点：

恢复时间长：需要串行处理被依赖的表，当表的数量多，或数据量较大时，会增加恢复时间。此外，外键关系复杂时，对依赖顺序的排序会显著增加耗时，增加恢复时间。

资源利用率低：串行恢复无法充分利用多核CPU和多线程的优势，资源利用率低，整体恢复效率不高。

3.3 外键转为普通索引

方案概述：

在临时实例对表完成重命名后、数据导入回源实例前，将外键约束转换为普通索引，恢复过程中不进行外键验证。

实现方式：

第一步，将外键约束转换为普通索引；

ALTER TABLE orders_new
    DROP CONSTRAINT fk_customer_order,
    ADD INDEX customer_id_idx (customer_id);

第二步，执行表级恢复操作；

第三步，恢复完成后，不会自动重建外键约束，用户根据需要自行添加外键。

优点：

恢复速度快：由于不需要验证外键约束，恢复速度会显著加快。同时将外键转化为普通索引后，可以并行恢复父表与子表，提升恢复效率。

查询性能提升：将外键转化为普通索引后，可以提升查询性能，特别是在进行基于外键字段的查询时。

缺点：

数据不一致风险：恢复过程中未进行外键验证，可能会导致数据不一致，尤其是在父表和子表数据关系不完全匹配时。但相较于直接禁用外键检查，这种方法在数据一致性方面相对更可靠。

3.4 性能对比

在实际的测试中，使用TaurusDB 4U16G实例，恢复三张表，共 5GB 数据，以下是三种恢复方案的myloader导入时间对比：

图1 三种方案的恢复性能对比

从图1中可以看到，临时禁用外键约束检查的恢复速度最快，外键转为普通索引的恢复速度稍慢，但都明显好于串行恢复。

4. 总结

综上，在恢复性能方面，临时禁用外键约束检查和外键转化为普通索引的方案均优于传统串行恢复方法。比如，“临时禁用外键约束检查”，因跳过外键验证步骤，恢复速度更快，但也可能导致参照完整性问题，存在数据不一致的问题。“外键转化为普通索引”，避免了外键验证开销，但大数据量时，索引建立会比较慢。然而，也正是因为保留索引结构，让数据一致性更可靠。

通过对比几种外键约束表的表级时间点恢复方案后，TaurusDB 综合考虑了恢复效率与数据一致性，最终选择了“外键转换为普通索引”的方案。它不仅提升了恢复性能，还保障了数据的参照完整性，降低了数据不一致的风险。