在 Aurora 上的 ALGORITHM=INSTANT：哪些 ALTER TABLE 操作是真正的零停机时间

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the content, I’ll provide a Simplified‑Chinese translation while preserving the source link, markdown formatting, code blocks, URLs, and technical terms as requested.

概述

在高可用性的 Aurora MySQL 环境中，最小化模式更改期间的停机时间至关重要。传统的 ALTER TABLE 操作通常需要表锁，在操作期间阻塞读写——这对于具有严格正常运行时间要求的应用来说是不可接受的。为了解决此问题，引入了 ALGORITHM=INSTANT，它可以在不持有长时间元数据锁的情况下执行某些 ALTER TABLE 操作。更改会直接应用到表的元数据，而实际的数据修改则在后台线程中运行，从而允许并发的 DML 操作。该特性对于管理 CI/CD 流水线和实现平滑部署的 SRE 来说至关重要。

ALGORITHM=INSTANT 的工作方式

Aurora MySQL 8.0.x 和 MySQL 8.0.x 使用一种在线 DDL 引擎，支持 ALGORITHM=INSTANT。对于受支持的操作，过程如下：

1. 元数据更新 – 表的内部元数据结构几乎瞬间完成更新，只需要一次短暂的元数据锁。
2. 后台阶段 – 后台线程执行实际的数据修改。

对于修改表结构的操作（例如，添加列），引擎可能会创建一个新的内部表并将其与旧表交换。对于其他操作（例如，添加二级索引），后台工作则更直接。在后台阶段，表仍然可以进行读写，从而避免出现 “Error 1412: Cannot alter table … when there are active users or the table is locked”。

Use‑Case Example

想象一个电子商务平台在黑色星期五的高峰流量。一个关键的 bug 修复需要向 orders 表添加新列。使用 ALGORITHM=INPLACE 或 ALGORITHM=COPY 的传统 ALTER TABLE 可能导致显著的停机时间，造成数千美元的收入损失。对于兼容的操作——例如添加可为空的列——使用 ALGORITHM=INSTANT 可以在零感知停机的情况下部署修复，保持业务连续性和客户信任。

常见陷阱

• 并非所有操作都是真正的零停机时间。 添加生成列或修改列的默认值仍可能导致临时阻塞。
• 假设该子句保证即时执行。 单独使用 ALGORITHM=INSTANT 子句不足以保证；请通过系统表和日志验证结果。
• 忽视表的大小和复杂性。 大表或已有大量即时列的表可能会出现更长的后台阶段。

最佳实践

• 确保 Aurora MySQL 版本为 8.0.12 或更高。
• 监控 information_schema.innodb_tables 中的 instant_cols 计数，该计数显示使用即时 DDL 添加或修改的列数。
• 考虑 innodb_instant_alter_column_threshold 参数（默认 1024 字节）。将其设置为 0 会强制所有列操作使用 INSTANT，但需充分测试。
• 检查 aurora_alter_table_wait_for_commit 参数（默认 0），因为它可能影响并发事务期间的行为。

提示

始终通过检查操作前后的 SHOW CREATE TABLE 输出，以及监控 information_schema.innodb_tables 中 instant_cols 列的变化来验证 ALGORITHM=INSTANT 是否成功，尤其是针对列相关的 DDL。

示例会话

-- Session 1: hold a row lock
SET SESSION transaction_isolation = REPEATABLE READ;
BEGIN;
SELECT id FROM users WHERE id = 1 FOR UPDATE;

-- Session 2: perform an instant alter
ALTER TABLE users
    ADD COLUMN last_login DATETIME NULL DEFAULT NULL
    ALGORITHM=INSTANT, LOCK=NONE;

-- Session 1 can now commit or rollback without error
COMMIT;

警告

虽然 ALGORITHM=INSTANT 功能强大，但它并非万能钥匙。如果表中已有大量即时列（接近内部限制），或者 ALTER TABLE 操作需要大量数据重写，则后台阶段仍可能消耗大量 I/O 和 CPU 资源，进而影响整体系统性能。请在与生产负载相匹配的预演环境中测试这些操作。