MySQL throws ER_TABLE_NOT_LOCKED (SQLSTATE HY000) when a session tries to read or write a table that is not locked after a LOCK TABLES statement was issued in the same connection.
MySQL Error 1100: ER_TABLE_NOT_LOCKED occurs when a query touches a table that has not been explicitly locked after issuing LOCK TABLES. Lock every referenced table or end the lock session with UNLOCK TABLES to resolve the issue.
Table '%s' was not locked with LOCK TABLES
Error 1100 (ER_TABLE_NOT_LOCKED) signals that the current connection entered locked-tables mode by running LOCK TABLES, but the following statement references a table that was not included in the lock list. In this mode MySQL enforces manual locks to guarantee consistency.
The server blocks the statement to avoid reading or writing data without the expected lock, which could break transactional guarantees or return inconsistent results.
The error always appears within the same session that executed LOCK TABLES.
.
Issuing SELECT ... FOR UPDATE, INSERT, UPDATE, or DELETE on a table that was not named in the preceding LOCK TABLES clause immediately triggers the error.
Mixing privileged statements such as ALTER TABLE or CREATE TEMPORARY TABLE after LOCK TABLES without adding them to the lock list also causes error 1100.
Always lock every table you plan to touch. Add missing tables to the LOCK TABLES statement with the correct read or write lock type, then retry the query.
If you no longer need explicit locks, end locked-tables mode with UNLOCK TABLES or by closing the connection. This restores normal implicit locking behavior and clears the error.
Multiple-table UPDATEs - Ensure both source and target tables are listed in LOCK TABLES with WRITE locks.
Stored procedures - When a procedure performs LOCK TABLES, every internal statement must reference only the locked tables or unlock before accessing others.
Minimize use of explicit table locks. Prefer transactions with InnoDB’s row-level locking when possible.
When explicit locks are required, create helper functions to generate the full lock list automatically, or use Galaxy’s AI copilot to expand LOCK TABLES statements based on detected table names.
ER_TABLE_NOT_LOCKED_FOR_WRITE (Error 1099) - Similar but triggered when attempting to write to a table locked READ ONLY. Acquire a WRITE lock.
ER_LOCK_OR_ACTIVE_TRANSACTION (Error 1192) - Signals a conflicting active transaction during a locking request. Commit or roll back the open transaction before locking.
The query references a table that was simply forgotten in the lock list.
A procedure called after locking touches additional tables not previously locked.
Creating or altering temporary tables after entering locked-tables mode raises the error because those tables were not declared.
Running DDL or administrative commands after LOCK TABLES without appropriate locks triggers the same error.
.
No. InnoDB uses row-level locks. Prefer transactions unless you have a special use case such as advisory locking or MyISAM tables.
UNLOCK TABLES implicitly commits any active transaction. Commit first if you need transactional consistency.
Yes, but every statement inside the procedure must honor locked-tables mode. Unlock before referencing tables outside the lock list.
Galaxy’s AI copilot highlights unlisted tables in a LOCK TABLES clause and auto-generates the full statement, reducing human error.
.avif)
.avif){kind=logo}
