Deadlocks in InnoDB ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction At that point, the lock request for the other client can be granted and it deletes the row from the table. 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  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. 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. For techniques to organize database operations to avoid deadlocks, see Section 15.7.5, “Deadlocks in InnoDB” . 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  variable. This section builds on the conceptual information about deadlocks in Section 15.7.5.2, “Deadlock Detection” . It explains how to organize database operations to minimize deadlocks and the subsequent error handling required in applications. Deadlocks are a classic problem in transactional databases, but they are not dangerous unless they are so frequent that you cannot run certain transactions at all. Normally, you must write your applications so that they are always prepared to re-issue a transaction if it gets rolled back because of a deadlock. InnoDB  uses automatic row-level locking. You can get deadlocks even in the case of transactions that just insert or delete a single row. That is because these operations are not really “atomic” ; they automatically set locks on the (possibly several) index records of the row inserted or deleted. You can cope with deadlocks and reduce the likelihood of their occurrence with the following techniques: •At any time, issue  SHOW ENGINE INNODB STATUS  to determine the cause of the most recent deadlock. That can help you to tune your application to avoid deadlocks. •If frequent deadlock warnings cause concern, collect more extensive debugging information by enabling the  innodb_print_all_deadlocks  variable. Information about each deadlock, not just the latest one, is recorded in the MySQL error log. Disable this option when you are finished debugging. 15.7.5.3 How to Minimize and Handle Deadlocks Disabling Deadlock Detection 15.7.5.2 Deadlock Detection 3100