14.5.5.2 Deadlock Detection and Rollback

When deadlock detection is enabled (the default), InnoDB automatically detects transaction deadlocks and rolls back a transaction or transactions to break the deadlock. InnoDB tries to pick small transactions to roll back, where the size of a transaction is determined by the number of rows inserted, updated, or deleted.
当开启(默认)死锁检测时，InnoDB自动检测事务死锁并回滚事务或事务打破死锁。。innodb尝试挑选一个较小的事务来回滚，事务的大小是由insert,update,delete影响到的行数来决定的
InnoDB is aware of table locks if innodb_table_locks = 1 (the default) and autocommit = 0, and the MySQL layer above it knows about row-level locks. Otherwise, InnoDB cannot detect deadlocks where a table lock set by a MySQL LOCK TABLES statement or a lock set by a storage engine other than InnoDB is involved. Resolve these situations by setting the value of the innodb_lock_wait_timeout system variable.
如果设置了 innodb_table_locks = 1和 autocommit = 0的情况下，InnoDB可以意识到表锁并且InnoDB上面的MySQL层也能知道行级锁,InnoDB无法检测由MySQL LOCK TABLES语句设置的表锁或由InnoDB以外的存储引擎设置的锁所涉及的死锁。通过设置innodb_lock_wait_timeout系统变量的值来解决这些情况。
When InnoDB performs a complete rollback of a transaction, all locks set by 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 statement may be preserved. This happens because InnoDB stores row locks in a format such that it cannot know afterward which lock was set by which statement.
当 InnoDB 执行事务的完整回滚时, 事务设置的所有锁都会被释放。但是, 如果仅由于错误而回滚单个 SQL 语句, 则该语句设置的某些锁可能会被保留。发生这种情况的原因是, InnoDB 以一种格式存储行锁,以致于它无法知道哪个锁由哪个语句设置。
If a SELECT calls a stored function in a transaction, and a statement within the function fails, that statement rolls back. Furthermore, if ROLLBACK is executed after that, the entire transaction rolls back.
如果一个事务中的SELECT调用了存储函数并且函数中的语句失败，那么这个语句将进行回滚，此外, 如果在之后执行ROLLBACK, 整个事务将回滚。
If the LATEST DETECTED DEADLOCK section of InnoDB Monitor output includes a message stating, “TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION,” this indicates that the number of transactions on the wait-for list has reached a limit of 200. A wait-for list that exceeds 200 transactions is treated as a deadlock and the transaction attempting to check the wait-for list is rolled back. The same error may also occur if the locking thread must look at more than 1,000,000 locks owned by transactions on the wait-for list.
如果innodb监控输出的LATEST DETECTED DEADLOCK片段 包含了 “TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION,”信息说明，这表明等待列表的事务数已达到200的限制。等待超过200事务的列表被视为死锁，而试图检查等待列表的事务将回滚。如果锁定线程必须查看等待列表中事务所拥有的超过100万个以上的锁，那么可能也会出现同样的错误。
For techniques to organize database operations to avoid deadlocks, see Section 14.5.5, “Deadlocks in InnoDB”.
用于组织数据库操作以避免死锁的技术，请看Section 14.5.5, “Deadlocks in InnoDB”.

Disabling Deadlock Detection

On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. Deadlock detection can be disabled using the innodb_deadlock_detect configuration option.
在高并发系统中, 当大量线程等待相同的锁时，死锁检测会导致速度变慢。。有时候，当发生死锁时，禁用死锁检测并依赖innodb_lock_wait_timeout设置进行事务回滚可能更有效。可以使用 innodb_deadlock_detect 选项禁用死锁检测。

标签：14.5,5.2,transaction,Detection,死锁,InnoDB,innodb,deadlock,wait
来源： https://blog.51cto.com/itzhoujun/2354769