为什么我更喜欢 ALGORITHM=COPY 而不是 ALGORITHM=INPLACE？

Question

由于 MySQL 5.6 引入了在线 DDL，该ALTER TABLE命令可以选择具有ALGORITHM=INPLACE或ALGORITHM=COPY指定。在线 DDL的概述指出，默认情况下，INPLACE尽可能使用，并暗示（从未完全说明）该INPLACE算法比算法便宜COPY。

那么我有什么理由必须ALGORITHM=COPY在ALTER TABLE声明中指定？

Answer 1

是的，在某些情况下您可以指定COPY，但这可能是出于性能以外的其他原因。

重要的是要了解 MySQL 在 5.6 版中引入了新功能 - 在线 DLL 处理。它没有删除离线处理。所以需要区分这2种模式：

1. 某些操作仍然只能在离线模式下工作。有关可以或不能就地执行的 DDL 操作的列表，请参见表 15.10，“ DDL 操作的在线状态摘要”。

2. Online 和 Offline 模式下的操作行为略有不同，因此出于兼容性原因，您可以选择“旧”一种。

一些例子（请提出更多建议）：

1. 在 MySQL 5.6 之前创建的 InnoDB 表不支持ALTER TABLE ... ALGORITHM=INPLACE包含临时列 ( DATE,DATETIME或TIMESTAMP) 且尚未使用ALTER TABLE ... ALGORITHM=COPY. 在这种情况下，ALTER TABLE ... ALGORITHM=INPLACE操作返回错误。

2. ADD PRIMARY KEYin 子句COPY mode默默地转换NULL为该数据类型的默认值（0 表示 INT，空字符串表示 varchar），IN_PLACE而不会这样做。

使用 ALGORITHM=COPY 子句，尽管主键列中存在 NULL 值，但操作仍会成功；数据被悄悄更改，这可能会导致问题。

更喜欢的另一个原因COPY：

您为其指定 ALGORITHM=COPY 或 old_alter_table=1 的操作，如果需要，强制执行表复制行为，以便在特定场景中实现精确的向后兼容性。

MySQL手册虽然没有讲实际场景，但你可以想象一些。例如，开发人员在ALTER INDEX操作期间依赖于表被锁定，因此表是只读的或完全锁定的，并且在索引重建期间有一个读取静态表的进程。