Examine these entries from the general query log: All UPDATE statements reference existing rows. Which describes the outcome of the sequence of statements?

Question

Exhibit

Options

• AConnection 24 experiences a lock wait timeout.
• BConnection 25 experiences a lock wait timeout.
• CA deadlock occurs immediately.
• DAll statements execute without error.
• EA deadlock occurs after innodb_lock_wait_timeout seconds.

• A
  3% (1)
• B
  14% (5)
• C
  20% (7)
• D
  6% (2)
• E
  57% (20)

Explanation

Option E is correct because the query log sequence creates a classic circular lock dependency between the two connections - each holds a row lock the other needs - but with innodb_deadlock_detect disabled (or otherwise not triggering immediately), InnoDB cannot detect the cycle in real time. Instead, it falls back to innodb_lock_wait_timeout: once that interval elapses, the waiting transaction is rolled back and the deadlock is surfaced as an error.

Why the distractors fail:

• A & B describe a one-sided lock wait timeout, where only one connection is blocked; here both are mutually blocked, which is a deadlock, not a simple timeout victim.
• C ("immediately") would be correct if innodb_deadlock_detect = ON (the default), but the log context implies detection is disabled, so there is no instant cycle check.
• D is wrong because the mutual lock conflict absolutely prevents silent success.

Memory tip: Think of innodb_deadlock_detect as a smoke detector and innodb_lock_wait_timeout as a fire sprinkler - if the detector is off, the sprinkler still activates eventually, but only after the timer runs out. "Deadlock after timeout" = sprinkler mode.

No community discussion yet for this question.