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

自从MySQL 5.6引入在线DDL以来，该ALTER TABLE命令可以选择使用ALGORITHM=INPLACE或ALGORITHM=COPY指定。该在线DDL概述，默认情况下，票据INPLACE尽可能选用，并暗示（而没有相当说明它），该INPLACE算法是便宜不是COPY一个。

那我为什么要ALGORITHM=COPY在ALTER TABLE声明中指定原因呢？

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

重要的是要了解MySQL引入了新功能-版本5.6中的在线DLL处理。它没有删除脱机处理。因此，需要区分这两种模式：

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

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

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

1. MySQL的5.6之前创建InnoDB表不支持ALTER TABLE ... ALGORITHM=INPLACE针对包括时间列（表DATE，DATETIME或TIMESTAMP），并使用尚未重建ALTER TABLE ... ALGORITHM=COPY。在这种情况下，ALTER TABLE ... ALGORITHM=INPLACE操作将返回错误。

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

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

首选的另一个原因COPY：

您指定了ALGORITHM = COPY或old_alter_table = 1的操作，以便在特殊情况下为实现精确的向后兼容性而强制执行表复制行为。

尽管MySQL手册没有讨论实际情况，但是您可以想象一些。例如，开发人员在ALTER INDEX操作过程中依靠表被锁定，因此表是只读的或完全锁定的，并且有一个过程在索引重建期间读取静态表。

@Stoleg可能是最好的答案，但这是另一个答案。有道理的猜测是=COPY，如果出现严重的bug，开发者会作为逃生门而离开=INLINE。ALTER即使新功能被破坏，这也将使用户继续使用。

多年来，我已经看到过类似的事情（在标志sql_mode，my.cnf设置等）。新版本的目的显然是要推出新的更好的功能。

优化标志属于这一类，但是还有更多的理由挂在前面的操作上—优化器有时总是“做错事”；可能性太多了。

在支持InnoDB表空间加密的MySQL版本中，当您更改表以添加加密时，不必要使用复制算法来完成更改。