How to fix ERROR 1150: Delayed insert thread couldn't get lock in MySQL

MySQLINTERMEDIATEMEDIUMUpdated Dec 23, 2025· 92 views

ERROR 1150 occurs when a DELAYED insert thread cannot acquire the lock it needs to write to a table, often due to conflicting LOCK TABLES or FLUSH statements. This error is rare in modern MySQL (5.7+) since INSERT DELAYED has been deprecated and removed; if you encounter it, switch to regular INSERT statements or batch inserts.

Quick fix

Fixes 1150

SELECT VERSION();
  1. Identify your MySQL version and INSERT DELAYED usage
  2. Replace INSERT DELAYED with regular INSERT statements
  3. Use batch inserts for performance-critical scenarios
  4. For truly asynchronous inserts, use application-level queuing
mysql — error
SELECT VERSION();
ERROR 1150: Delayed insert thread couldn't get lock

What this error means

This error is associated with MySQL's deprecated INSERT DELAYED feature, which was designed to defer insert operations asynchronously. When a delayed insert thread attempts to acquire a table lock to complete the pending insert, it fails because another connection holds an incompatible lock (such as a READ lock from LOCK TABLES or FLUSH TABLES). The delayed handler thread terminates without writing the queued data, resulting in potential data loss. MySQL 5.6 deprecated INSERT DELAYED, MySQL 5.7 began ignoring the keyword with a warning, and MySQL 8.0+ removed support entirely. Modern MySQL engines like InnoDB never supported DELAYED inserts at all.

Typical symptoms

  • INSERT DELAYED query fails with "ERROR 1150: Delayed insert thread couldn't get lock"
  • Rows inserted with INSERT DELAYED do not appear in the table
  • Error occurs when INSERT DELAYED coincides with LOCK TABLES or FLUSH TABLES on the same table
  • Application logs show delayed insert operations timing out or being silently dropped
  • More common in older MySQL versions (5.1, 5.5) with MyISAM tables

Common causes

  1. Using INSERT DELAYED while LOCK TABLES READ is active on the target table
  2. FLUSH TABLES statement executing while delayed insert threads are processing
  3. INSERT DELAYED used with MyISAM tables when LOCK TABLES is held by another connection
  4. ALTER TABLE or other DDL statements blocking the delayed insert handler thread
  5. FLUSH TABLES WITH READ LOCK (FTWRL) running concurrently with INSERT DELAYED
  6. Using deprecated INSERT DELAYED on MySQL 5.7+ instead of regular INSERT

How to fix "ERROR 1150: Delayed insert thread couldn't get lock"

1Identify your MySQL version and INSERT DELAYED usage

Check which MySQL version you're running:

sql
SELECT VERSION();

Search your application code and queries for any use of INSERT DELAYED:

bash
# In application code
grep -r "INSERT DELAYED" .
grep -r "insert delayed" . --ignore-case

If you're on MySQL 5.7+, INSERT DELAYED is no longer functional. Proceed to the next step to replace it with regular INSERT statements.

2Replace INSERT DELAYED with regular INSERT statements

Convert all INSERT DELAYED statements to standard INSERT statements. This is the primary fix:

Before (deprecated):

sql
INSERT DELAYED INTO logs (user_id, action, timestamp) 
VALUES (123, 'login', NOW());

After (correct):

sql
INSERT INTO logs (user_id, action, timestamp) 
VALUES (123, 'login', NOW());

For InnoDB tables (the default in MySQL 5.7+), regular INSERT is efficient and supports row-level locking, avoiding the lock contention that plagued INSERT DELAYED.

3Use batch inserts for performance-critical scenarios

If you were using INSERT DELAYED for throughput improvement, replace it with batch inserts (multiple VALUES in one statement):

Before:

sql
INSERT DELAYED INTO events (user_id, event_type) VALUES (1, 'click');
INSERT DELAYED INTO events (user_id, event_type) VALUES (2, 'scroll');
INSERT DELAYED INTO events (user_id, event_type) VALUES (3, 'close');

After (batch insert):

sql
INSERT INTO events (user_id, event_type) 
VALUES 
  (1, 'click'),
  (2, 'scroll'),
  (3, 'close');

Batch inserts are 83% faster than individual inserts in benchmarks and avoid the deadlock issues of INSERT DELAYED.

4For truly asynchronous inserts, use application-level queuing

If your workload requires fire-and-forget inserts, implement async queueing at the application level instead of relying on the database:

Option 1: Message Queue (RabbitMQ, Redis Streams, AWS SQS)

javascript
// Pseudo-code
await messageQueue.enqueue({
  table: 'logs',
  data: { user_id: 123, action: 'login' }
});
// Worker process consumes and batches inserts

Option 2: Staging Table with Batch Processing

sql
-- Insert into temporary staging table (fast, no locks)
INSERT INTO logs_staging (user_id, action) VALUES (123, 'login');

-- Periodically batch merge into main table
INSERT INTO logs SELECT * FROM logs_staging LIMIT 1000;
DELETE FROM logs_staging WHERE id IN (SELECT id FROM logs LIMIT 1000);

This gives you the performance benefits of async inserts without the reliability issues of INSERT DELAYED.

5Verify the fix by running test inserts

Test your updated insert statements:

sql
-- Test regular insert
INSERT INTO your_table (col1, col2) VALUES ('value1', 'value2');
SELECT * FROM your_table WHERE col1 = 'value1'; -- Should return 1 row

-- Test batch insert
INSERT INTO your_table (col1, col2) 
VALUES ('v1', 'v2'), ('v3', 'v4'), ('v5', 'v6');
SELECT COUNT(*) FROM your_table WHERE col1 IN ('v1', 'v3', 'v5'); -- Should return 3

Confirm that ERROR 1150 no longer appears and all rows are inserted successfully.

Advanced notes

INSERT DELAYED was removed from MySQL due to its inherent design flaws: the delayed handler thread uses mutexes in an order incompatible with the rest of the server, leading to numerous deadlocks and data loss scenarios. The combination of table locks (LOCK TABLES, FLUSH TABLES), DDL operations (ALTER TABLE), and DELAYED insert threads created unpredictable interactions that even affected replication and multi-table operations.

For modern applications requiring true asynchronous writes, do not rely on database features. Instead, use external message queues (RabbitMQ, Redis, Kafka) or implement staging tables with periodic bulk inserts. These approaches are more reliable, scale better across multiple servers, and avoid the synchronization issues that plagued INSERT DELAYED.

If you're upgrading from MySQL 5.5 or earlier, grep your codebase thoroughly for INSERT DELAYED. MySQL 5.7+ silently converts DELAYED inserts to regular inserts with a warning, which may mask migration issues.

Frequently asked questions

What does "1150" mean?
This error is associated with MySQL's deprecated INSERT DELAYED feature, which was designed to defer insert operations asynchronously. When a delayed insert thread attempts to acquire a table lock to complete the pending insert, it fails because another connection holds an incompatible lock (such as a READ lock from LOCK TABLES or FLUSH TABLES). The delayed handler thread terminates without writing the queued data, resulting in potential data loss.
How do I fix "1150"?
ERROR 1150 occurs when a DELAYED insert thread cannot acquire the lock it needs to write to a table, often due to conflicting LOCK TABLES or FLUSH statements. This error is rare in modern MySQL (5.7+) since INSERT DELAYED has been deprecated and removed; if you encounter it, switch to regular INSERT statements or batch inserts.
What causes "1150"?
Using INSERT DELAYED while LOCK TABLES READ is active on the target table FLUSH TABLES statement executing while delayed insert threads are processing INSERT DELAYED used with MyISAM tables when LOCK TABLES is held by another connection
Is the "1150" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading