Symptom triage
For MySQL 8.4 InnoDB, these symptoms suggest investigations, not unique diagnoses. The linked schedules reproduce selected mechanisms under their stated configuration. Confirm the cause before changing isolation, ending a connection, or retrying work.
| Symptom | First check | Possible mechanism | Scoped response |
|---|---|---|---|
| Updates wait, then finish | Waiter/blocker views | Row-lock waits | Shorten the holding transaction; end it only after checking rollback and client effects |
Errno 1205 | Row-lock views and metadata-lock state | Row-lock timeout or metadata timeout | For whole-operation retry, ROLLBACK first; check innodb_rollback_on_timeout |
Errno 1213 | Deadlock reports and counter | Opposite order or another lock cycle | Retry the rolled-back transaction within a safe application boundary; investigate actual locks |
| INSERT waits without a duplicate row | data_locks and wait edges | Gap/range locks | Narrow locking reads; READ COMMITTED changes range protection and retains constraint-related gap locks |
| Wrong numbers with successful commits | Anomaly catalog and application invariants | Lost updates or write skew | Select a repair for the actual rule; single-row repairs alone do not protect every cross-row invariant |
| Storage growth | History health and workload | Retained undo, insufficient purge capacity, or other storage growth | Investigate retaining views and purge; this metric does not measure disk bytes |
| DDL waits and later queries queue | processlist and metadata-lock state | Metadata-lock queue | Bound metadata acquisition with lock_wait_timeout; investigate holders |
The InnoDB error-handling manual states: "A transaction deadlock causes InnoDB to roll back the entire transaction." For an InnoDB row-lock timeout, statement-only rollback is the default, innodb_rollback_on_timeout=OFF; ON requests transaction rollback. The timeout schedule asserts the OFF case. Do not infer identical rollback scope from identical error numbers in different operations.
Successful commits do not establish a valid application invariant. Concurrency counters can expose waits and purge history; they do not detect the business-rule violations shown in the anomaly catalog. Application checks and coordinated writer protocols are separate work.