MySQL InnoDB lock knowledge points

Abstract ：

• Ordinary select Statements are not locked , Bottom use " Read the snapshot " technology , Snapshot read is when a write operation occurs copy A new copy of the data , Other read operations read Old version data , Here the “ Multiple data versions ” To achieve .

• Special that can be locked select sentence : 

1.   select ... lock in share mode
2.   select ... for update

• update、delete Default plus  “ Exclusive lock (X)”, insert Probability plus  “ Insert intention lock ”(gap A kind of lock )

• Concurrent Insert There is also a probability of deadlock ,  InnoDB Use Insert intention lock , Can improve the insert concurrency

Shared lock (S) 

• The shared lock is used to lock the data row, which can only be read , namely session1 Get the shared lock , other session Can only read , Can't write

Application scenarios ： At some point , Inventory needs to be counted , But at this time, others can count , But no one is allowed to modify ,

demo：  select ... lock in share mode

 

Exclusive lock (X) 

• Update、Delete The default is to add and exclude other locks , Prohibit any other client from simultaneously “ Reading and writing ” Locked data rows

Be careful : select ... for update Will add X lock

Self increasing lock

• mysql Primary keys are often used AUTO_INCREMENT, When insert When the value of auto increment column is not specified , The system will automatically write the self incrementing value , Add at this time “ Self increasing lock ” , Self increasing lock is table lock Table locks , So in order to control insert Performance of ,mysql Introduce a configuration item ：innodb_autoinc_lock_mode

• innodb_autoinc_lock_mode Configuration item ：0、1、2. among 0 The worst performance ,1 In the middle ,2 Fastest but with probability id Discontinuous

Intent locks  

• Intention lock is a table lock .
• InnoDB Intention locks are used to make table locks and row locks coexist . What is the meaning of its existence ？ Suppose such a situation ,sessionA Use “X lock ” Lock the tableA One line of records , and sessionB Use the watch lock lock tableA, here sessionB I want to change it A The locked record , If there is no intention lock at this time , They are conflicting . A more vivid example , Some restaurant has 10 A private room , Zhang San uses customer service to 1 Room No. is reserved , Other people will not be able to book the private room , But at this time, Li Si said that he would cover the whole restaurant , Customer service also allowed . That three belt 10 Go to dinner alone , Li Si took hundreds of people to dinner , Zhang San's table 10 I'm going to fight with Li Si's men .
• The above situation requires an intention lock , Zhang San ordered 1 Room No , Then the whole restaurant was locked , Others want to rent a restaurant , Customer service looked at the restaurant and decided to lock it , Just say you can't rent a restaurant , But the others 9 A private room ( Row lock ) have access to . At this time, someone is going to ask a question , Go directly to the restaurant to lock the watch ？ What, you , Watch lock means that the whole watch is locked , other 9 You can't book any private rooms , Still making so much money ？？？. So the intent lock is a weak table level lock . Direct watch lock Poor performance , So use intent lock .
• summary ： Intent locks , This is to solve the problem that row locks exist in the table , It is not allowed to lock the meter at the same time , But you can lock other rows .

Clearance lock  (gap lock )

• When we retrieve data using range conditions rather than equality conditions , And request sharing or exclusive lock ,InnoDB It will lock the index entries of existing data records that meet the conditions ; For records whose key values are within the range of conditions but do not exist , be called “ The gap (GAP)”,InnoDB It's also about this “ The gap ” Lock , This kind of lock mechanism is called gap lock (NEXT-KEY) lock .
• In a nutshell ： Within the conditions , But the record lines that do not exist , By other business insert These nonexistent records , Will produce unreal reading , Or uncontrollable situations .
• Life cases ： Young and dangerous Two gangs “ Hong Xing ” and “ Dongxing ” Each represents two mysql session. One day , Hongxing's chenhaonan goes to the Causeway Bay store to collect protection fees , altogether 4 The store number is ：100,101、108、110 Four stores , Chenhaonan succeeded in collecting this 4 The protection fee of the store , the second day The crow in Dongxing sent someone to build a shop 105. Chenhaonan came again to collect the protection fee , The two gangs started fighting , Chenhaonan said , I run this street ,100～110 The record of ID It's all my business , Crows are not happy , You are a great man , This is our shop in Dongxing . Conflict arises at this time , therefore gap Lock has come to help chenhaonan , When Causeway Bay was swept up by chenhaonan gap lock ,100～110 All the stores are managed by chenhaonan , Others are not allowed to cover the shop ！！！！！

Typical deadlock cases

session 1	session 2
begin	begin
update table A set name='A' where id=1	update table B set name='B' where id=3
update table B set name='B' where id=3	update table A set name='A' where id=1
commit	commit

The above cases ： Two sessions wait for each other to release X lock , Until the lock wait times out , There's a deadlock .