Unlike the MyISAM storage engine, which supports only table locks. InnoDB can lock individual records, which is known as row level locking. This can bring great performance benefits for a wide variety of applications, but it unfortunately also introduces a problem: potential deadlocks. Let’s say, for example, that thread 1 acquires an exclusive lock on record A. In the meantime, thread 2 acquires an exclusive lock on record B. Thread 1 then, while still holding the lock on A, attempts to acquire a lock on B, but has to wait for thread 2 to release it. In the meantime, thread 2 is trying to lock record A while still holding the lock on B. Thus neither one can progress, and we have a deadlock condition.
While it is possible to use an algorithm that avoids potential deadlocks, such a strategy can very easily cause severe performance degradation. InnoDB approaches the problem from a different angle. ---innodb采用的策略不是去避免死锁,而是检测死锁,并释放.Normally deadlocks are very rare, especially if the application was written with some awareness of the problem. Therefore, instead of preventing them, InnoDB just lets them happen, but it periodically runs a lock detection monitor that frees the deadlock “prisoner” threads and allows them to return and report to the client that they have been aborted because they’ve been waiting for their lock longer than the value of this option. Note that the deadlock monitoring thread does not actually examine the sequence of the locks each thread is holding to figure out the existence of a logical database deadlock. --并不真正的去计算死锁是否存在. Rather, it assumes that if a certain thread has exceeded the time limit in waiting for a lock that it requested, it is probably logically deadlocked. Even if it is not, it doesn’t matter—the user would appreciate getting an error message rather than waiting indefinitely while nothing productive is being accomplished.---原理很简单:凡是被阻塞超过一定时间的,都被认为是死锁.
