<p>MySQL error 1684 warns that a table was ignored because another session is modifying its structure at the same time.</p>
<p>MySQL Error 1684: ER_WARN_I_S_SKIPPED_TABLE appears when the server skips a table because a concurrent DDL statement holds its metadata lock. Wait until the DDL finishes or schedule your change in a maintenance window to resolve the warning.</p>
Table '%s'.'%s' was skipped since its definition is being
Error 1684 – ER_WARN_I_S_SKIPPED_TABLE – signals that MySQL ignored a table during an operation because another session was changing the table definition. The server chooses safety by skipping the locked object rather than blocking the entire statement.
MySQL avoids long waits and potential deadlocks by continuing the information_schema operation while emitting a warning. This behavior is common during SHOW, BACKUP, or metadata queries that touch many tables.
The message is a warning. The original statement usually completes, but the data from the skipped table is missing. Applications that rely on complete results must handle this case.
The warning appears in MySQL 5.7, 8.0, and MariaDB forks that implement metadata locking. Exact phrasing may vary slightly between versions.
Yes. In Galaxy’s SQL editor you can run metadata lock diagnostics, view running sessions, and share one-click snippets with teammates to coordinate DDL windows, reducing the chance of this warning.
Another session is adding or dropping a column at the moment your query accesses information_schema.
Using ALTER TABLE ... ALGORITHM=COPY holds a global lock that blocks readers, triggering the skip.
Logical backup utilities traverse all tables; if a table is locked, they log this warning.
Automated migration tools that run many DDL statements in parallel often overlap with monitoring queries.
Occurs when a transaction waits too long on a row or metadata lock.
Signals a deadlock between two or more transactions, requiring rollback.
Another HY000 class warning but related to JSON casting, not locking.
Raised when a referenced table is missing rather than locked.
No rows are corrupted. The statement simply omits the locked table.
You can if partial results are acceptable. For backups or audits, you should not ignore it.
Query performance_schema.metadata_lock_info and information_schema.processlist to see user, host, and running SQL.
Investigate long-running DDL, replication lag, or hung sessions, then kill or restart them after assessing risk.
.avif)
.avif){kind=logo}
