> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/server/reference/error-codes/mariadb-error-codes-1200-to-1299/e1213.md).

# Error 1213: Deadlock found when trying to get lock; try restarting transaction

| Error Code | SQLSTATE | Error              | Description                                                        |
| ---------- | -------- | ------------------ | ------------------------------------------------------------------ |
| 1213       | 40001    | ER\_LOCK\_DEADLOCK | Deadlock found when trying to get lock; try restarting transaction |

## Possible Causes and Solutions

Two or more transactions wait for locks that the others hold, so none of them can continue. For example, one transaction updates row 1 and then row 2, while another updates row 2 and then row 1. InnoDB detects the deadlock right away, rolls back one of the transactions, and returns this error to it. The other transactions continue.

The **whole transaction** that gets the error is rolled back, not only the last statement. A deadlock is not a server fault. It can happen in any application that runs transactions concurrently.

To solve the error:

* Retry the whole transaction. This is the normal way to handle a deadlock, and the application should be ready to do it.
* Make deadlocks less likely:
  * Access tables and rows in the same order in all transactions.
  * Keep transactions short, and commit them as soon as possible.
  * Add indexes, so that statements lock fewer rows. An `UPDATE` or `DELETE` without a usable index locks every row it scans.
  * Lock all the rows you need at the start, with [SELECT … FOR UPDATE](/docs/server/reference/sql-statements/data-manipulation/selecting-data/for-update.md).

To see what caused the most recent deadlock, run [SHOW ENGINE INNODB STATUS](/docs/server/reference/sql-statements/administrative-sql-statements/show/show-engine-innodb-status.md) and look at the `LATEST DETECTED DEADLOCK` section. It shows both transactions, the statements they ran, the locks they held and waited for, and which transaction was rolled back. To log every deadlock in the [error log](/docs/server/server-management/server-monitoring-logs/error-log.md), set [innodb\_print\_all\_deadlocks](/docs/server/server-usage/storage-engines/innodb/innodb-system-variables.md#innodb_print_all_deadlocks). [innodb\_deadlock\_report](/docs/server/server-usage/storage-engines/innodb/innodb-system-variables.md#innodb_deadlock_report) sets how much detail the report contains.

If [innodb\_deadlock\_detect](/docs/server/server-usage/storage-engines/innodb/innodb-system-variables.md#innodb_deadlock_detect) is OFF, InnoDB doesn't look for deadlocks. The transactions then wait until [innodb\_lock\_wait\_timeout](/docs/server/server-usage/storage-engines/innodb/innodb-system-variables.md#innodb_lock_wait_timeout) and fail with [error 1205](/docs/server/reference/error-codes/mariadb-error-codes-1200-to-1299/e1205.md) instead.

In Galera Cluster, this error is also returned when a transaction conflicts with a transaction that another node committed first. Retry the transaction in this case too.

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>

{% @marketo/form formId="4316" %}