以下限制适用于在线 DDL 操作:
在
TEMPORARY TABLE
上创建索引时,会复制该表。如果表上有
ON...CASCADE
或ON...SET NULL
约束,则不允许使用ALTER TABLE
子句LOCK=NONE
。在就地在线 DDL 操作完成之前,它必须等待持有表上元数据锁的事务提交或回滚。在线 DDL 操作在其执行阶段可能短暂需要表上的独占元数据锁,并且在操作的最终阶段更新表定义时始终需要一个锁。因此,持有表上元数据锁的事务可能会导致在线 DDL 操作阻塞。持有表上元数据锁的事务可能是在在线 DDL 操作之前或期间启动的。长时间运行或不活动的持有表上元数据锁的事务可能会导致在线 DDL 操作超时。
运行就地在线 DDL 操作时,运行
ALTER TABLE
语句的线程将应用来自其他连接线程在同一表上并发运行的 DML 操作的在线日志。应用 DML 操作时,可能会遇到重复键条目错误(错误 1062 (23000):重复条目),即使重复条目只是暂时的,并且会被在线日志中的后续条目还原。这类似于InnoDB
中外键约束检查的概念,其中约束必须在事务期间保持。InnoDB
表的OPTIMIZE TABLE
被映射到ALTER TABLE
操作,以重建表并更新索引统计信息并释放聚簇索引中未使用的空间。辅助索引的创建效率不高,因为键是按照它们在主键中出现的顺序插入的。通过添加对重建常规和分区InnoDB
表的在线 DDL 支持,OPTIMIZE TABLE
受支持。对于在 MySQL 5.6 之前创建的包含时间列(
DATE
、DATETIME
或TIMESTAMP
)并且尚未使用ALGORITHM=COPY
重建的表,不支持ALGORITHM=INPLACE
。在这种情况下,ALTER TABLE ... ALGORITHM=INPLACE
操作将返回以下错误:ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.
以下限制通常适用于涉及重建表的大型表上的在线 DDL 操作:
没有机制可以暂停在线 DDL 操作或限制在线 DDL 操作的 I/O 或 CPU 使用率。
如果操作失败,回滚在线 DDL 操作的成本可能很高。
长时间运行的在线 DDL 操作可能会导致复制延迟。在线 DDL 操作必须在源上运行完毕,然后才能在副本上运行。此外,在副本上完成 DDL 操作后,才会在副本上处理在源上并发处理的 DML。
有关在大型表上运行在线 DDL 操作的其他信息,请参阅 第 17.12.2 节,“在线 DDL 性能和并发”。