EC
2005
MariaDBERRORCommonLockingHIGH confidence

Deadlock found when trying to get lock

Production Risk

Medium — one transaction is rolled back; application must handle retries.

What this means

A deadlock was detected in InnoDB. Two or more transactions are mutually waiting for locks held by each other. InnoDB resolves deadlocks by rolling back the transaction with the least cost.

Why it happens
  1. 1Two transactions acquiring locks in opposite orders on the same rows.
  2. 2Long-running transactions holding locks while waiting for more.
  3. 3Implicit lock escalation in complex multi-table updates.
  4. 4Gap locks conflicting during concurrent inserts.
How to reproduce
trigger — this will error
trigger — this will error
-- T1: UPDATE t SET v=1 WHERE id=1; UPDATE t SET v=1 WHERE id=2;
-- T2: UPDATE t SET v=2 WHERE id=2; UPDATE t SET v=2 WHERE id=1; -- deadlock

expected output

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction.

Fix 1

Retry the transaction on deadlock

Retry the transaction on deadlock
-- In application code: catch ER_LOCK_DEADLOCK (1213) and retry

Why this works

Deadlocks are transient; a retry usually succeeds.

Fix 2

Access tables and rows in a consistent order across transactions

Access tables and rows in a consistent order across transactions
-- Always lock rows in primary key order to prevent deadlocks

Why this works

Consistent locking order eliminates the circular wait condition.

What not to do

✕

Sources
Official documentation ↗

MySQL 8.0 — 2005 ER_LOCK_DEADLOCK2 / 1213 ER_LOCK_DEADLOCK

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All MariaDB errors