PolarDB MySQL 8.0.2版支持的DDL执行方式

本文基于云原生数据库PolarDB MySQL版 8.0.2版本，对常见DDL的执行方式进行了说明，方便用户查询和了解DDL的行为，评估DDL操作风险，降低对业务的影响。

概述

在MySQL生态中，DDL是一类非常复杂的操作，包括Index操作、Primary Key操作、Column操作、Table操作、Foreign Key操作、Generated Column操作等多种不同类型的操作。DDL操作不仅耗时长、消耗硬件资源多，而且其中涉及的锁表操作，如果失误就可能影响正常业务，造成灾难性的影响。

PolarDB MySQL版在DDL操作方面经过多年的经验积累和持续的功能迭代，目前在性能和锁稳定性方面取得了长足的进步。

本文从以下几方面介绍了8.0.2版本的支持情况：

• 是否允许并发DML（是否锁表）：非锁表的DDL（支持Online DDL功能）只在修改元数据时申请表互斥锁（持续时间一般不超过1秒），在表结构变更期间允许对目标表进行读写操作，提高了在生产环境中的响应速度和可用性。相反，不支持Online DDL功能的语句会全程锁表，不支持并发的写入操作，当DDL操作持续时间较长时，可能会对业务操作造成重大影响。

• 是否重建表（持续时间长短）：此类DDL需要根据新的表结构重新创建Primary Key以及所有二级索引，通常需要花费较长时间。

• 是否秒级完成（是否只修改元数据）：只修改元数据的操作不修改表数据，即DDL不会随着表规模变大而影响性能，一般秒级可完成。

• 是否支持并行DDL（多线程加速）：对于大表创建索引、重建表等场景，PolarDB支持并行DDL、多线程加速DDL，最高提升15~20倍的性能，详细内容请查看PolarDB的在线分区维护功能。

  说明

  • 对于需要锁表的DDL操作，当需要重建表（大量数据迁移导致DDL耗时长，且无法通过Instant DDL、Parallel DDL加速），并且业务无法留出足够的时间窗时，可以考虑DMS无锁变更或者gh-ost等方式。此类第三方工具执行速度慢，在大表或者高并发场景增量数据过多的情况下容易失败。

  • 在使用第三方工具时，任何工具（例如gh-ost、pt-osc或DMS无锁变更）都至少会在切表，即修改元数据时拿MDL-X锁，进而导致短暂的锁表，Online DDL也有同样的现象。所以在执行DDL时，依然需要确保DDL不会被大事务或大查询所堵塞，规避短暂锁表导致的连接打满等问题。

  云原生数据库PolarDB MySQL版内核团队在全链路MDL锁治理方面也做了相当多的优化工作，详细内容请查看深度解析PolarDB DDL锁的优化和演进。

下文中罗列了云原生数据库PolarDB MySQL版 8.0.2版本中，部分常见DDL操作的执行方式。

Index操作

①在添加表的第一个全文索引时，如果没有用户定义的FTS_DOC_ID列，会导致额外的重建表操作。

Primary Key操作

Column操作

①秒级加列功能仅支持将列添加到表的末尾，并且表需要已创建主键（否则可能会因为最末尾的隐式主键导致秒级加列失败）。秒级加列功能不支持压缩表（ROW_FORMAT=COMPRESSED）、全文索引的表和临时表。不支持秒级加列时，增加列默认使用INPLACE DDL，需要全表重建，此时支持通过并行DDL加速，允许并发DML。

②扩展VARCHAR长度时，存储VARCHAR列长度所需的字节数需要保持一致，才能支持快速修改。具体来说，对于0-255Bytes的VARCHAR列，只需要一个Byte存储长度。而对于大于等于256Bytes的VARCHAR列，就需要两个Bytes存储长度。只有控制VARCHAR列长度的扩展范围，比如从0~255Bytes，或者从256Bytes到更大的范围，才能支持ALTER TABLE只修改元数据。也就是说，当修改VARCHAR列长度从小于256Bytes到大于256Bytes的长度时，PolarDB默认走Copy DDL类型，即全程都是锁表的，不支持DML写操作，仅支持读操作。

当您不确定自己修改VARCHAR列的范围是否满足上述条件时，可以使用ALGORITHM=INPLACE指定采用INPLACE算法执行当前DDL操作。此时，如果不支持快速列扩展，则会直接报错。下面是一个简单的示例。

ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
ERROR 0A000: ALGORITHM=INPLACE is not supported. 
Reason: Cannot changecolumn type INPLACE. Try ALGORITHM=COPY

VARCHA类型属于变长存储类型，磁盘仅存储实际长度，因此建议您在使用VARCHA类型的字段时，考虑将最大长度直接调整到256以上，避免扩展字段时可能需要走copy算法。

Table操作

①如果新的character发生变化，需要使用COPY DDL重建表。

②通过ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE重新整理表中的碎片时，带全文索引的表不支持INPLACE。

Generated Column操作

①由于增加Stored Column表达式涉及SQL/Server层，因此不支持Online DDL。

Foreign Key操作

①只有在关闭了foreign_key_checks开关，并且只修改元数据的情况下，才支持INPLACE DDL。否则只支持COPY DDL，需要全程锁表。

分区表操作

①支持分区级元数据锁，将参数loose_partition_level_mdl_enabled的值设为true后，DDL不影响不涉及的分区上的DML，详细信息请查看在线分区维护。

②只有RANGE和LIST分区支持。

③只支持QUERY。