以下限制适用于联机 DDL 操作:
在 上创建索引时会复制该表
TEMPORARY TABLE
。如果表上有或约束,则 不允许使用 该
ALTER TABLE
子句 。LOCK=NONE
ON...CASCADE
ON...SET NULL
在在线 DDL 操作完成之前,它必须等待持有表元数据锁的事务提交或回滚。在线 DDL 操作在其执行阶段可能会短暂地需要对表进行独占元数据锁定,并且在更新表定义时在操作的最后阶段始终需要一个。因此,在表上持有元数据锁的事务可能会导致联机 DDL 操作阻塞。在表上持有元数据锁的事务可能在联机 DDL 操作之前或期间启动。对表持有元数据锁的长时间运行或非活动事务可能会导致在线 DDL 操作超时。
对外键关系中的表执行的在线 DDL 操作不会等待在外键关系中的另一个表上执行的事务提交或回滚。该事务在它正在更新的表上持有独占元数据锁,在外键相关表上持有共享元数据锁(外键检查需要)。共享元数据锁允许在线 DDL 操作继续进行,但会在最后阶段阻止该操作,此时需要独占元数据锁来更新表定义。当其他事务等待在线 DDL 操作完成时,这种情况可能会导致死锁。
运行联机 DDL 操作时,运行该
ALTER TABLE
语句的线程会应用其他连接线程在同一表上同时运行的 DML 操作的联机日志。应用 DML 操作时,可能会遇到重复键条目错误 ( ERROR 1062 (23000): Duplicate entry ),即使重复条目只是暂时的,并且会被在线日志中的后续条目恢复。这类似于外键约束检查的想法,InnoDB
其中约束必须在事务期间保持。OPTIMIZE TABLE
对于一个InnoDB
表,映射到一个ALTER TABLE
操作以重建表并更新索引统计信息和释放聚簇索引中未使用的空间。在 5.6.17 之前,没有在线 DDL 支持此操作。二级索引的创建效率不高,因为键是按照它们在主键中出现的顺序插入的。从 5.6.17 开始,OPTIMIZE TABLE
通过添加在线 DDL 支持来支持重建常规表和分区InnoDB
表。不支持 在 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 使用率的机制。
直到 MySQL 5.7.6 引入了用于监控
ALTER TABLE
进度的 Performance Schema 阶段事件,在线 DDL 操作的进度监控能力受到限制。请参阅 使用性能模式监视 InnoDB 表的 ALTER TABLE 进度。如果操作失败,在线 DDL 操作的回滚可能代价高昂。
长时间运行在线 DDL 操作会导致复制滞后。联机 DDL 操作必须先在源上完成运行,然后才能在副本上运行。此外,在副本上并发处理的 DML 仅在副本上的 DDL 操作完成后才在副本上处理。
有关在大型表上运行在线 DDL 操作的其他信息,请参阅 第 14.13.2 节,“在线 DDL 性能和并发性”。