MySQL Deadlock Detection: Check the Latest Deadlock and Current Waits

To inspect the last detected InnoDB deadlock, run SHOW ENGINE INNODB STATUS; and find LATEST DETECTED DEADLOCK. To investigate transactions waiting for data locks now, inspect performance_schema.data_lock_waits. These answer different questions: a past deadlock is not a list of current blockers.
This guide covers MySQL 8.0 and 8.4 with InnoDB. The examples observe existing state; they do not reproduce a deadlock, terminate a session, or change database settings.

A deadlock is a cycle of transactions waiting for locks held by one another. With InnoDB deadlock detection enabled, the server breaks the cycle by rolling back a victim transaction. The affected application can receive error 1213, SQLSTATE 40001.
A lock wait alone does not prove a deadlock: one transaction can wait for another without a cycle. A lock-wait timeout is also a different event and should not be diagnosed from a deadlock report alone.
Check the version and current detection setting without changing either:

If detection is disabled, do not assume that the absence of a new deadlock report rules out a cycle. Record that setting for the DBA instead of changing it during diagnosis.

Use an account with the PROCESS privilege:

In the mysql command-line client, \G can replace the semicolon for vertical display. Other SQL clients can display the Status field directly.

Within LATEST DETECTED DEADLOCK, inspect:

The report retains the latest detected deadlock, not a searchable history. A newer event can replace the one you need. The statement shown for a transaction is not its complete earlier statement sequence, so correlate the report with authorized application traces.

An absent section means there is no retained report available here. It is not proof that the application has never experienced deadlocks. If the timestamp belongs to another incident, keep that distinction in your notes.

With Performance Schema available and SELECT access to the table, inspect a bounded result:

Each row identifies a requesting transaction and a transaction blocking its lock request. The thread identifiers are Performance Schema thread IDs, not connection IDs. Rows can change as transactions progress, and the result is only a sample, not a complete wait graph or a deadlock verdict.

An empty result means this query returned no matching waits at observation time. It does not contradict an earlier deadlock: InnoDB may already have resolved that event. This table covers data-lock waits, not every reason a query can be delayed, such as metadata locking.

Look for the transaction pattern behind the conflict:

• Different access order: compare the order in which the transaction paths touch the same rows or tables.
• Range or gap locking: identify the index and requested lock range; do not infer the conflict from query text alone.
• Related rows or constraints: check whether uniqueness or foreign-key checks connect the operations.
• Long transaction scope: look for earlier work or application delays that kept locks held before the reported statement.

These are investigation leads, not automatic prescriptions. Ask the DBA and application owner to review transaction boundaries, access order, indexes, and the application's handling of a rolled-back transaction. Any retry design must account for the entire transaction and external side effects. Changing isolation levels, replacing write statements, or adding locking reads requires case-specific review.

InnoDB status can reveal SQL, object names, account information, and record contents. Keep the full report in an access-controlled incident record; share only a redacted excerpt. Managed services may restrict diagnostic privileges. If access is denied, request an authorized capture rather than granting yourself broader access.
Run these observations selectively. Read-only does not mean zero load, and LIMIT caps returned rows rather than guaranteeing a fixed execution cost. Do not kill a transaction or enable extra logging based solely on this snapshot.
For the wider diagnostic sequence, see MySQL performance tuning. For Releem product information, see MySQL performance monitoring.