Can MySQL online DDL with LOCK=NONE still stall application queries during the final metadata-lock cutover?

The decisive factor in whether the final metadata-lock cutover stalls application queries is the duration of existing transactions, not the rate of incoming queries. MySQL's ALTER TABLE ... ALGORITHM=INPLACE LOCK=NONE permits concurrent DML throughout the bulk of the operation, but it still requires a brief exclusive metadata lock (MDL) at the start to validate the new definition and at the final cutover phase to install it. If any session holds an MDL on the table - typically from a long-running transaction, backup, or analytics query - the cutover blocks until that session releases its lock. Incoming query volume only determines how long the resulting queue persists after the block occurs; it does not prevent the block itself.

For a small application with modest traffic and no long-running transactions, native online DDL with LOCK=NONE is generally sufficient. The final exclusive MDL window is typically under one second, which produces a noticeable but brief pause rather than a sustained stall. However, if any session maintains an MDL across the DDL's execution - common in workloads with ad-hoc reports, scheduled backups, or replication lag - the cutover can wait indefinitely, and queued queries accumulate, creating visible traffic disruption.

Before running the change in production, verify that the intended ALGORITHM=INPLACE is supported for the specific table alteration. Some column or type changes silently fall back to a COPY-style rebuild if INPLACE is unavailable, especially without LOCK=NONE. Detect this by checking SHOW CREATE TABLE for the Engine and Algorithm fields, or by querying the Performance Schema for existing MDL holders:

SELECT * FROM performance_schema.metadata_locks WHERE object_schema = 'your_db' AND object_name = 'your_table';

If the query returns rows, those sessions hold an MDL and will block the cutover. Additionally, run a test ALTER TABLE on a staging copy with a held MDL and monitor the Performance Schema to observe the blocking behavior in a controlled environment.

One remaining diagnostic detail: does your workload include any long-running transactions or recurring queries that typically hold an MDL on the target table? Answering this determines whether the risk of a cutover stall is low enough for native DDL or whether an external online-schema-change tool should be the default.