MySQL, deadlock problem

First of all, in fact, the possibility of causing deadlock may be different for everyone, so the focus is not on how to solve the problem, but on analysis. Maybe the problem I encountered does not apply to others, but I have to figure out this situation first. , which table and which field generated the resource requisition, and then analyze and solve it.

After logging in to mysql, use show engine innodb status; to view the last deadlock situation. After the

query , it is displayed
------------------------
LATEST DETECTED DEADLOCK
- -------------
Below the block is the requisition description information of the deadlock,

which will describe things 1, things 2.... in the execution of a certain statement When the resource is requisitioned for which field of which table, what type of lock is occupied. For

example following information

RECORD LOCKS space id 47 page no 305 n bits 328 index PRIMARY of table `test`.`t_test` trx id 13806 lock_mode X locks gap before rec insert intention waiting

This describes the type of
lock , RECORD, lock mode X, when preparing to apply for an insert intention lock, at the 328-bit position of the space 47 page number 305 where the PRIMARY primary key index is located Requisition occurred.


Here you need to be familiar with several concepts
Lock mode, X stands for exclusive lock, S stands for shared lock, IX stands for table-level exclusive lock, IS stands for table-level shared lock, in the case of multi-thread/session/transaction, It is possible to use them at the same time. For the specific compatibility relationship, please refer to the official documentation.
http://dev.mysql.com/doc/refman/5.5/en/innodb-locking.htmlThe

type of lock is also described in the above document
RECORD is a record level lock
GAP is a record interval range lock
Next-Key Locks Locks for an interval range greater than a value and less than or equal to a certain value
These refer to indexes. In fact, when operating table data, the indexes will be locked first, especially PRIMARY and UNIQUE, which are uniquely constrained indexes. , During the operation, the database will first query the index in the database and then perform the corresponding operation.


Knowing this, we can analyze the resource requisition of locks. For
example following operation

table model is
primary key (self-increment, with primary key index)
other columns

Start transaction 1
transaction 1, execute the delete statement to delete an existing value (lock this The index of the record)
transaction 1, insert a new record, apply for a lock, wait for the lock to be authorized,
start transaction 2
, transaction 2, execute the delete statement to delete an existing value that is different from transaction 1 (lock the index of this record)
Transaction 2, insert a new record, apply for a lock, and wait for the lock to be authorized
. Submit transaction 1
to submit operations above transaction 2

without causing resource competition, because the two deletes delete the value of the specified id.

But when the above operation, if delete deletes a non-existing value, then the non-existing index will be searched in all indexes, and an interval range will be found, such as the index is 10, 20, to delete 15, then The range of index 10~20 will be locked, and at the same time, another transaction will also lock this range, which will cause resource competition.
The inserts of the two transactions are waiting for the range range locked by delete to be released, and then execute the insert, which causes a deadlock

. Of course, the above is only one of the cases. The cause of the deadlock is resource competition, so first check which resource is blocked. Contention, which statement is executed, and what the structure of the table is.