PolarDB:DDL operation guide for PolarDB for MySQL

What can go wrong with a DDL operation

A single ALTER TABLE statement can do any of the following:

• Hold an exclusive table lock for its entire duration, blocking all reads and writes

• Trigger a full table rebuild that takes hours on large tables

• Cause connection queuing: later queries pile up behind the DDL, timing out or disrupting your application

• Spike IOPS and CPU usage, affecting other workloads on the same cluster

PolarDB for MySQL has made significant improvements to DDL performance and lock behavior across versions. This guide helps you identify the risk profile of each operation before you run it.

DDL execution algorithms

PolarDB automatically selects the most efficient algorithm in order: INSTANT → INPLACE → COPY. Understanding each algorithm helps you predict the impact of a DDL operation.

DDL operations that allow concurrent reads and writes during execution are called Online DDL. Online DDL minimizes production impact.

Contact us

If you have any questions about DDL operations, please contact technical support.

Preview DDL behavior before execution

Because DDL behavior can be affected by table structure, parameter configurations, and enabled features, the actual behavior may differ from the tables in this guide. Use EXPLAIN DDL to preview exactly how a DDL statement will execute before running it.

{ EXPLAIN | DESCRIBE | DESC } ALTER TABLE ...

EXPLAIN DDL returns:

• Whether the DDL can execute successfully

• The algorithm it will use (INSTANT, INPLACE, or COPY)

• Whether it will rebuild the entire table

• Whether concurrent DML is allowed during execution

• Whether it will be blocked by uncommitted transactions

• Whether parallel DDL acceleration is supported, and the degree of parallelism if so

For more information, see EXPLAIN DDL.

DDL behavior by operation

The tables below show DDL behavior across PolarDB for MySQL versions. Four columns describe the behavior of each operation:

• Concurrent DML — whether concurrent reads and writes are permitted during execution

• Rebuilds table — whether the operation triggers a full table rebuild (long-running for large tables)

• Metadata only — whether the operation modifies only metadata (completes in seconds)

• Parallel DDL — whether the operation supports parallel DDL acceleration

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

ALTER TABLE test MODIFY COLUMN b char(1) CHARACTER SET utf8mb4 DEFAULT NULL, ALGORITHM=INPLACE;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

Choose an execution method

When a DDL operation uses the INSTANT or INPLACE algorithm, run it directly using the kernel (Online DDL). This is the fastest and most stable approach.

When a DDL operation uses the COPY algorithm, the table is locked for the entire duration. In this case, consider using lock-free DDL in DMS or a tool such as gh-ost to allow reads and writes during execution. These approaches are slower and may fail on large tables or high-concurrency workloads due to excessive incremental data.

Even with third-party tools, an MDL-X lock is acquired during table switching (when metadata is modified), temporarily blocking the table. To address this, enable the nonblocking DDL feature or the preemptive DDL feature.

Related topics

• Parallel DDL — accelerate large-table DDL with multi-threaded execution

• EXPLAIN DDL — preview DDL execution behavior before running it

• instant add column — add columns without rebuilding the table

• Implementing lock-free schema evolution — run COPY-algorithm DDL without impacting your application

• Online partition maintenance — partition DDL that does not block DML on unaffected partitions

• Nonblocking DDL and preemptive DDL — reduce MDL lock contention during schema changes

If you have questions about DDL operations, contact technical support.