<p>MySQL throws Error 1725 when a statement tries to change a table that is locked by an ongoing foreign key check.</p>
<p>MySQL Error 1725: ER_TABLE_IN_FK_CHECK occurs when a table is locked for a foreign key consistency check, blocking DDL or DML statements. Wait for the checking session to finish or release its metadata lock to resolve the issue.</p>
Table is being used in foreign key check.
MySQL raises Error 1725 (SQLSTATE HY000) when an ALTER TABLE, DROP TABLE, TRUNCATE, RENAME, or LOCK operation targets a table that is currently being validated for foreign key integrity. During the validation MySQL places a metadata lock on the table, blocking conflicting operations.
The server aborts the incoming statement immediately with this error instead of waiting, helping you avoid long lock waits. Fixing it requires releasing or waiting for the lock that the foreign key check holds.
The error appears when another session is adding, dropping, or checking a foreign key that references the same table. A long-running transaction, replication SQL thread, or online schema change tool can hold the metadata lock for longer than expected.
Even within the same session, running ALTER TABLE t1 ADD CONSTRAINT followed by another DDL on t1 before COMMIT can trigger the error because the first statement’s internal check has not finished.
Identify the session performing the foreign key check, wait for it to finish, or terminate it if safe. Use performance_schema.metadata_locks or SHOW ENGINE INNODB STATUS to find the blocking thread. After the lock is gone, rerun your statement.
If the check belongs to your own uncommitted transaction, COMMIT or ROLLBACK will immediately release the lock. Where possible, reorder DDL so that foreign key creation happens last to minimize lock time.
During a deployment script, concurrent ALTER TABLE statements may clash. Serialize the changes or wrap them in distinct transactions to avoid overlap.
Replication delay can leave slave servers holding a lock while applying a foreign key DDL. Monitor applier lag and run DDL during maintenance windows.
Batch foreign key operations, keep transactions short, and avoid interactive sessions that start a DDL and stay idle. Use pt-online-schema-change or gh-ost for hot migrations that do not lock the original table.
Track metadata locks with performance_schema and set up alerts to catch long-running foreign key checks early.
Error 150 (foreign key constraint fails) indicates the referenced data or index is missing rather than a lock. Error 1213 (deadlock) can surface if multiple sessions wait on each other’s metadata locks. Both require different resolution steps.
A transaction that adds or drops a foreign key and remains uncommitted keeps the table locked, blocking other DDL.
Two sessions altering the same table at once can collide when one enters the foreign key check phase.
The replication SQL thread or a logical backup tool might be performing the check, holding the metadata lock until completion.
Indicates data or index inconsistency rather than a lock.
Occurs when sessions wait on each others locks, requiring a rollback.
Appears if a CREATE TABLE collides with an existing object of the same name.
No. The metadata lock is taken before the variable is evaluated, so the error can still occur.
Yes if you are certain it is idle or belongs to a failed job. Always verify with PROCESSLIST_INFO first.
Usually milliseconds, but large tables or replication lag can extend it to minutes.
Galaxy’s lock monitor highlights active metadata locks and flags long-running foreign key checks, letting you address them before deployment scripts fail.
.avif)
.avif){kind=logo}
