下面的限制应用于Online DDL操作：

• 在临时表上创建索引时，会复制表。
• 如果表上有 ON…CASCADE或ON…SET NULL约束，那么alter table语句不允许有lock=none子句。
• 在一个就地更新的online DDL操作完成前，它必须等待所有持有MDL锁的事务提交或回滚。一个online DDL操作在执行阶段会短暂的要求获取表的元数据锁，并且在更新表定义时，通常会在操作的最终阶段也获取元数据锁。因此，持有表的元数据锁的事务会阻塞online DDL操作。持有元数据锁的事务在一个online DDL操作开始前或执行过程中被开启。一个持有元数据锁的长事务或不活跃的事务会导致online DDL操作超时。
• 在运行一个就地更新的online DDL操作时，执行alter table语句的线程会对在同一张表上执行DML操作的并发线程应用在线日志。在执行DML操作时，可能会遇到重复键错误（ERROR 1062 (23000): Duplicate entry）,即使这个重复键可能只是暂时的，可能会随后被随后的条目撤销（revert）。这和InnoDB中的外键约束检查类似（在事务执行期间必须一直持有这个约束）。
• 对InnoDB表的OPTIMIZE TABLE 操作会被映射为一个alter table操作，会重建表并更新索引统计信息、释放聚簇索引中未使用的空间。创建二级索引的效率不高，因为键是按照它们出现在主键索引中的顺序插入的。optimize table 增加了online DDL支持，可以用来重建常规索引和InnoDB分区表。
• 在MySQL5.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.

• 下面的限制通常适用于大表上的会重建表的online DDL操作：

  • 没有暂停online DDL或控制其I/O或CPU使用量的方法。
  • 如果online DDL操作失败，回滚的代价很高。
  • 运行时间过长的online DDL操作可能会导致复制延迟。一个online DDL操作必须在源数据库上执行完成之后才能在副本上执行。此外，在源数据库上执行过的DML操作必须在副本上的DDL操作执行完成之后，才能在副本上执行。

  想了解更多对大表执行online DDL操作的信息，请查阅章节15.12.2,“Online DDL操作的性能和并发性”。