Mysql · XB Field Notes

InnoDB deadlocks roll back the whole victim transaction

Thu, 20 Apr 2028 00:00:00 +0000

An InnoDB deadlock occurs when transactions form a cycle of incompatible lock requests. With deadlock detection enabled, InnoDB chooses a victim and rolls back that entire transaction so another participant can proceed. The application receives error 1213 with SQLSTATE 40001. Retrying only the statement that reported the error omits earlier work that was rolled back with it.

When it breaks

Do not assign one rollback rule to every lock error. Under the default innodb_rollback_on_timeout=OFF, a lock-wait timeout rolls back the waiting statement while earlier statements in the transaction remain pending. Enabling that server option changes timeout rollback to the whole transaction. A deadlock already rolls back the whole victim transaction regardless of that default timeout behavior.

Victim selection is not a contract that a particular session always loses. Applications must inspect the actual error and retry the complete logical transaction with bounded attempts. Keep irreversible external effects out of an automatically replayed transaction unless they have a separate deduplication contract. A disconnected commit response is also not equivalent to a confirmed deadlock rollback.

Check it quickly

Use three fresh administrative MySQL 8.4 client sessions, A, B, and observer O, against a disposable instance. Start the clients in autocommit mode. Disable client automatic reconnection so session identity remains stable. The recorded run used MySQL 8.4.11. In O, create an unused fixture schema and verify detection is enabled and timeout rollback uses its default statement scope:

CREATE DATABASE xbcatm_deadlock_lab;
USE xbcatm_deadlock_lab;
CREATE TABLE accounts (id INT PRIMARY KEY, balance INT NOT NULL) ENGINE=InnoDB;
INSERT INTO accounts VALUES (1,100),(2,100);
SELECT @@innodb_deadlock_detect,@@innodb_rollback_on_timeout;

The settings should be one and zero. In A, start an operation adding ten to both accounts, initially locking account one:

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=10;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;

In B, start an operation adding one hundred, initially locking account two:

USE xbcatm_deadlock_lab;
SET SESSION innodb_lock_wait_timeout=30;
SET @increment=100;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=2;

In A, request the row B holds. This statement waits:

UPDATE accounts SET balance=balance+@increment WHERE id=2;

Before A’s thirty-second lock timeout, run the opposing request in B:

UPDATE accounts SET balance=balance+@increment WHERE id=1;

One session receives error 1213; identify it as the victim. The other update completes. Run this only in the surviving session:

COMMIT;

In O, inspect the committed state:

SELECT id,balance FROM accounts ORDER BY id;

Both balances are 110 if A survived, or 200 if B survived. The victim’s earlier update is absent too. The recorded run selected B, leaving 110 in both rows. In the victim’s existing session, its session variable still records the original increment. Retry the whole operation, now acquiring rows in consistent order:

SELECT @increment;
START TRANSACTION;
UPDATE accounts SET balance=balance+@increment WHERE id=1;
UPDATE accounts SET balance=balance+@increment WHERE id=2;
COMMIT;

In O, verify the combined outcome:

SELECT id,balance FROM accounts ORDER BY id;

Both balances must now be 210. Next, contrast a timeout. In O, reset the fixture:

UPDATE accounts SET balance=100;

In A, hold account one:

START TRANSACTION;
UPDATE accounts SET balance=balance+1 WHERE id=1;

In B, change account two and set a short wait:

SET SESSION innodb_lock_wait_timeout=1;
START TRANSACTION;
UPDATE accounts SET balance=balance+5 WHERE id=2;

Still in B, request A’s row:

UPDATE accounts SET balance=balance+5 WHERE id=1;

This produces error 1205 with SQLSTATE HY000. In B, inspect its own pending work:

SELECT id,balance FROM accounts ORDER BY id;

B reads 100 and 105. In O, committed readers still see 100 and 100:

SELECT id,balance FROM accounts ORDER BY id;

The timeout did not undo B’s earlier five-unit change. Explicitly discard the remaining transactions, first in B:

ROLLBACK;

Then in A:

ROLLBACK;

Finally, in O, confirm both original balances and remove the fixture:

SELECT id,balance FROM accounts ORDER BY id;
DROP DATABASE xbcatm_deadlock_lab;

The check distinguishes rollback scope through actual values, rather than relying only on an error message. Stop on unexpected results and roll back open fixture transactions before cleanup.

Reduce cycles without assuming they disappear

Acquire shared business resources in consistent order, keep transactions short, and use appropriate indexes to avoid locking more records than the operation needs. Range operations and secondary-index maintenance can add lock interactions beyond the two primary-key rows shown here. Consistent application ordering reduces a known cycle; it is not proof that every possible deadlock has been removed.

Use SHOW ENGINE INNODB STATUS to examine the latest detected deadlock, and capture broader history when incident frequency warrants it. Correlate the involved statements and lock order with the application transaction, not just the final failed statement. Retry complete work within a deadline, distinguish timeout semantics, and verify the business result before treating recovery as successful.

Sources

MySQL 8.4 InnoDB error handling, complete deadlock rollback and configurable timeout rollback scope, checked 2026-09-12.
MySQL 8.4 deadlock example, reproducing a cycle and examining the selected victim, checked 2026-09-12.
MySQL 8.4 InnoDB locking, record and range locks involved in concurrent operations, checked 2026-09-12.

InnoDB covering indexes carry the query's columns

Fri, 03 Mar 2028 00:00:00 +0000

A covering index contains the columns needed to evaluate a particular query and return its requested values. In InnoDB, secondary-index records also carry the primary-key columns, so a query can be covered without explicitly listing the primary key again in the secondary-index definition. Coverage is a relationship between one query and an index, not a permanent property that applies to every query against the table.

When it breaks

Adding a projected column can remove coverage. An index that supplies an identifier and timestamp may not contain the large payload that a later application change begins selecting. The optimizer can still use that same index to locate matching rows, then obtain missing values from the clustered records. Index use and covering access are different facts.

Coverage also does not guarantee a selective access path. A wide scan can be fully covered while examining many entries. Column order, predicates, sorting requirements, and row estimates still matter. Do not interpret Using index as evidence that a query is fast, or confuse it with Using index condition, which describes index condition pushdown rather than complete projection coverage.

InnoDB visibility checks qualify the usual index-only explanation. Secondary records do not contain the same hidden transaction metadata as clustered records. Delete-marked secondary entries or pages changed by newer transactions can require clustered-record lookups to obtain the correct visible version. A covering plan is therefore not a universal promise of zero clustered access under concurrent MVCC activity.

Check it quickly

Use a fresh MySQL 8.4 instance and a client session with permission to create a disposable schema. The recorded run used MySQL 8.4.11. Ensure xbcatm_index_lab is unused, stop on unexpected SQL errors, and keep the same session so its selected database remains active. Create ten thousand rows, with one hundred paid orders and a deliberately wider payload:

CREATE DATABASE xbcatm_index_lab;
USE xbcatm_index_lab;
CREATE TABLE orders (
 id INT PRIMARY KEY,
 status VARCHAR(10) NOT NULL,
 created_at DATETIME NOT NULL,
 payload VARCHAR(1000) NOT NULL,
 INDEX by_status_created (status,created_at)
) ENGINE=InnoDB;
INSERT INTO orders
WITH digits(n) AS (
 SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3
 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6
 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9
)
SELECT number+1,IF(MOD(number+1,100)=0,'paid','open'),
 TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (number+1) SECOND,
 REPEAT('x',640)
FROM (SELECT a.n+10*b.n+100*c.n+1000*d.n AS number
 FROM digits a CROSS JOIN digits b CROSS JOIN digits c CROSS JOIN digits d) AS numbered;
ANALYZE TABLE orders;
SELECT COUNT(*),SUM(status='paid') FROM orders;

The final count must be ten thousand and one hundred. The secondary index contains status and creation time explicitly; InnoDB supplies the primary identifier implicitly. Inspect and run a query that needs only those values:

EXPLAIN SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

The recorded tabular plan reports by_status_created and Using index. The analyzed plan identifies a covering index lookup and returns twenty rows. Result identifiers are one hundred, two hundred, and so on through two thousand, ordered by the timestamp and identifier. These are checked results on populated data, not a plan inferred from an empty schema.

Now request the payload as well:

EXPLAIN SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

The recorded plan still uses by_status_created, but loses Using index; the analyzed plan describes an index lookup without the covering qualification. This isolates the effect of changing the requested columns while keeping the filter, ordering, and index unchanged. The diagnostic execution does run the SELECT, so account for that when applying EXPLAIN ANALYZE to expensive real queries.

Remove the schema created for this exercise:

DROP DATABASE xbcatm_index_lab;

The timings from this tiny warm experiment are not a throughput or latency benchmark. Scheduling, caching, and instrumentation can outweigh the difference between two twenty-row reads. The verified conclusion concerns access shape and returned values, not a promised percentage reduction in physical I/O.

Pay for coverage deliberately

Appending columns to a secondary index consumes storage and buffer-pool capacity and increases maintenance when those indexed values change. Long primary keys enlarge secondary entries too. Cover the important narrow query rather than automatically copying a large payload into every index. Keep projected columns explicit so later application changes make their access requirements visible in review.

Compare representative plans, examined rows, foreground latency, and write cost before retaining a new index. Test with realistic selectivity and concurrent activity; a quiet fixture does not measure MVCC fallback frequency or replica maintenance cost. An index should earn its place through the workload it serves, not through the appearance of a desirable label in one explanation.

Sources

MySQL 8.4 clustered and secondary indexes, primary-key columns carried by secondary records, checked 2026-09-12.
MySQL 8.4 EXPLAIN output, index-use and covering-plan indicators, checked 2026-09-12.
MySQL 8.4 InnoDB multiversioning, clustered lookups required for secondary-index visibility checks, checked 2026-09-12.