MySQL locking and deadlock resolved

Generate the necessary conditions for deadlock

• A plurality of concurrent transactions (two or more)
• Each holds a lock things are (or are already waiting for the lock)
• Each transaction need to continue to hold the lock (to complete the transaction logic, you must also update more rows)

• Generating locked loop waiting among things, forming deadlock

  Conventional lock mode

• LOCK_S (read lock, shared lock)

• LOCK_X (write lock, exclusive lock)

  Lock attributes

• LOCK _REC_NOT_GAP (lock records)
• LOCK_GAP (GAP lock before recording)
• LOCK_ORDINARY (+ GAP simultaneously lock recording before recording, Next key lock)

• LOCK_INSERT_INTETION (insert intent lock)

  Lock combination (Properties + mode)

  Any combination

  Lock conflict matrix

  

Lock is added in there?

• The primary lookup key - locks applied on the master key
  as begin; select * from tt_copy where id
  lock case

  index PRIMARY of table test.tt_copy trx id 1101588 lock_mode X locks rec but not gap

• The ordinary index lookup - lock is applied to the common primary key index and
  as begin; select * from tt_copy force index
  lock case

  index idx_a of table test.tt_copy trx id 1101590 lock_mode X locks rec but not gap
  index PRIMARY of table test.tt_copy trx id 1101590 lock_mode X locks rec but not gap

Control operation locked relationship

The following special instructions are not RC isolation level

Insert

• No Unique key, inserted: RR isolation level or whether RC is the primary key plus LOCK_X + LOCK_REC_NOT_GAP

• 有Unique key

  Prior to insertion, the only constraint checking: LOCK_S + LOCK_ORDINARY
  front insert, inserted lock GAP Location: LOCK_INSERT_INTETION
  After insertion, the new data is inserted: LOCK_X + LOCK_REC_NOT_GAP

Delete

Delete all records meet the criteria: LOCK_X + LOCK_REC_NOT_GAP

Update

Update operation decomposition

• Step 1: positioning to the next record satisfying the query criteria (query process, similar to the Select / Delete)
• Step 2: delete the current record to locate (marked for deletion state)
• Step 3: Assembling update items, according to the updated items to the new insertion position
• Step 4: In the new insertion position, it determines whether a conflict exists Unique ( present when Unique Key )
• Step 5: insert (Unique absence of conflict) updated item
• Step 6: Repeat Step 1 to Step 5 of the operation , until the complete scanning range query

Update operation analysis

• Step 1，Step 2：Delete
• Step 3，Step 4，Step 5：Insert

Update

• 无Unique key：

  • All records in the query range, LOCK_X + LOCK_REC_NOT_GAP

• 有Unique key：

  • Find satisfy the conditions of the record: all records within the scope of the inquiry, LOCK_X + LOCK_REC_NOT_GAP
  • After updating the item exists uniqueness conflict: conflict lock on item, LOCK_S + LOCK_ORDINARY
  • The absence of conflict item unique updated: Item locking, LOCK_S + LOCK_GAP (omitted) After Update Location
  • The actual update operations: insert can be seen as a new record, LOCK_X + LOCK_REC_NOT_GAP

GAP lock

Those operations will add GAP lock?

• Read Committed (RC)): Unique Key unique constraint checks; the Purge operation;
• Repeatable Read (RC): RC on the basis of all the index range scans and indexes need to lock lookup (Update / Delete ...)
• Another plus GAP will lock: Under RR isolation level, the implementation of insert table has a unique index on duplicate update operation, in addition to the newly inserted record will add x not gap, but also on the adjacent recording plus x gap

How to get rid of GAP lock?

change the transaction isolation level to READ COMMITTED or enable the innodb_locks_unsafe_for_binlog system variable (which is now deprecated)

When will add next-key lock?

By default, InnoDB operates in REPEATABLE READ transaction isolation level. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows

Insert Intention Lock

An insert intention lock is a type of gap lock set by INSERT operations prior to（在...之前） row insertion.

to sum up

• One of the principles

• To analyze a deadlock, we must better business, to understand the logic of the entire transaction (not behind closed doors repairer)

• principle of the two `

• GAP lock is very complex, in order to reduce GAP locks, reducing the lead to deadlock GAP, try to choose isolation level Read Committed (RC + row based binlog, basically able to solve all the problems, without using Repeatable Read)
• Unique index appropriate to reduce, can be reduced due to lock deadlocks GAP (according to the service availability)

• The third principle

• In MySQL, different indexes to filter condition, the same operation to record (Update / Delete), easily creates dead
  lock.

• The fourth principle

• Under RC isolation level, if the Next Key appears (Gap lock) deadlock, indicating that there must be unique index table
• Deadlock multi-statement transaction generated, make sure the order of operation records of each statement, can greatly reduce deadlocks

---

Most are finishing this article from "deadlock - He Dengcheng - piece of a jigsaw --MySQL (InnoDB) deadlock analysis of the Road"