<p>MySQL cannot acquire a write lock on a log table because log tables are read-only for user sessions.</p>
<p>MySQL Error 1555 ER_CANT_WRITE_LOCK_LOG_TABLE happens when a statement tries to write-lock a server log table that is exposed in the mysql schema as read-only. Replace WRITE with READ or omit the log table from the LOCK TABLES clause to resolve the problem.</p>
You can't write-lock a log table. Only read access is
The error appears when a client issues LOCK TABLES ... WRITE, or any implicit write lock, on an internal log table such as general_log, slow_log or error_log. MySQL exposes these tables for auditing, but user sessions are restricted to read-only access. Attempting to promote the lock level fails and the server aborts the statement with SQLSTATE HY000.
The condition arises during explicit LOCK TABLES statements, CREATE TABLE ... SELECT that touches log tables, or any DML that forces a write lock through mysqldump with --lock-tables. It is common in backup scripts or migration tools that indiscriminately lock all tables, including those in the mysql system schema.
Failing to handle the error leaves sessions without the expected lock set, breaking transactional assumptions and potentially stalling backup pipelines. Automations that retry blindly may also saturate the server with repeated lock attempts.
Log tables are internally updated by the server and not designed for concurrent client writes. Granting write locks could block logging or corrupt diagnostic information. To preserve stability, the storage engine rejects any request stronger than a READ lock.
Exclude log tables from your LOCK TABLES list or downgrade the lock to READ. Backup tools should switch to --single-transaction or --skip-lock-tables. If you must copy data, create a temporary table with SELECT * FROM mysql.general_log WHERE ... instead of locking the original.
Always scope explicit locks to application tables only, use information_schema or performance_schema views for diagnostics, and adopt logical backups that rely on consistent snapshots rather than global table locks.
Backup or maintenance scripts that iterate through every table name and request WRITE locks inadvertently hit log tables.
The flag locks all tables for a stable export; log tables trigger the error because they cannot be write-locked.
Insert, update, or delete statements implicitly request write locks and therefore fail.
STOP SLAVE combined with ad-hoc LOCK TABLES commands can collide with log tables referenced for diagnostics.
Occurs when a session waits too long for another transaction to release a lock.
Signals cyclical waiting between transactions requiring rollback to resolve.
Triggered when a session tries to access a table it failed to lock explicitly.
No. MySQL reserves write operations on log tables for internal use only. Use SELECT or create a copy instead.
The restriction remains. Even with logging disabled, log tables stay read-only for user sessions.
READ locks are lightweight because the server only appends to the tables. Normal logging performance is unaffected.
Galaxy's AI copilot flags system tables when composing LOCK TABLES statements and suggests READ locks or filtered backups, reducing accidental write-lock attempts.
.avif)
.avif){kind=logo}
