(mysql.info.gz) InnoDB Deadlock detection

Info Catalog

(mysql.info.gz) InnoDB implicit command or rollback

(mysql.info.gz) InnoDB transaction model

(mysql.info.gz) Innodb deadlocks

 
 15.11.9 Deadlock Detection and Rollback
 ---------------------------------------
 
 `InnoDB' automatically detects a deadlock of transactions and rolls
 back a transaction or transactions to prevent the deadlock. Starting
 from MySQL 4.0.5, `InnoDB' tries to pick small transactions to roll
 back. The size of a transaction is determined by the number of rows it
 has inserted, updated, or deleted. Prior to 4.0.5, `InnoDB' always
 rolled back the transaction whose lock request was the last one to
 build a deadlock, that is, a cycle in the "waits-for" graph of
 transactions.
 
 Beginning with MySQL 4.0.20 and 4.1.2, `InnoDB' is aware of table locks
 if `innodb_table_locks=1' (1 is the default), and the MySQL layer above
 `InnoDB' knows about row-level locks.  Before that, `InnoDB' cannot
 detect deadlocks where a table lock set by a MySQL `LOCK TABLES'
 statement is involved, or if a lock set by another storage engine than
 `InnoDB' is involved. You have to resolve these situations by setting
 the value of the  `innodb_lock_wait_timeout' system variable.
 
 When `InnoDB' performs a complete rollback of a transaction, all the
 locks of the transaction are released. However, if just a single SQL
 statement is rolled back as a result of an error, some of the locks set
 by the SQL statement may be preserved. This is because `InnoDB' stores
 row locks in a format such it cannot know afterward which lock was set
 by which SQL statement.
 

Info Catalog

(mysql.info.gz) InnoDB implicit command or rollback

(mysql.info.gz) InnoDB transaction model

(mysql.info.gz) Innodb deadlocks