Database lock and transaction isolation level

There are read locks in the database (S lock )、 Write lock （X lock ）、 Table locks 、 Line lock, etc .S Lock and X Locks are mutually exclusive , You can't write while reading , You can't read while you're writing . Table lock and row lock actually refer to S Lock and X The scope of the lock ,S Lock and X Locks are useful 、 page 、 Or the whole table .

1. Table locks ： Low overhead , Locked fast , Generally, there is no dead end , But it affects concurrency , Poor concurrency . System upgrade , Use table locks during data migration
2.   Row lock ： Spending big , Lock the slow , There may be a deadlock , But it has little impact on concurrency performance , Good concurrency performance .

default select Does the statement have a lock ？ This depends on the transaction isolation level of the database engine .

Problems in concurrency ：

1. Dirty write ： No isolation level is added to the transaction
2. Dirty reading ： Add isolation level to the transaction
3. It can't be read repeatedly ： The isolation level is added to the transaction
4. Fantasy reading ： The isolation level is added to the transaction

The above problem can be solved through the isolation level of transactions . Transactions solve the above problems by locking , Lock the affected records before the transaction operation , Release the lock when the transaction ends . So if it passes S Lock and X Lock to achieve it ？

How to query the transaction isolation level and set the transaction isolation level ？

MySQL The four transaction isolation levels - Escape with a dream - Blog Garden

The relationship between the isolation level of transactions and locks ： 

1. There is no isolation level （ No business ？？？ incorrect , The transaction should be started , But there is no isolation level ）, This is the time when Dirty write （ It's also called Update missing ） problem ： Two threads operate on the same data , Update it , The update will be overwritten . How to solve this problem ？ The problem should be solved by locking , And it should be in Read UnCommit This isolation level is used to solve the problem

2.Read UnCommit Level （ Read uncommitted ）： This level should solve the problem of dirty writing （ By adding a lock ？ ？？ This conclusion needs to be confirmed ）, But there is also Dirty reading The problem of . Business A To update the data , Another concurrent transaction B Read the data , Business B Read the business A Data not submitted in （ Rolled back ）, This is dirty reading . How to solve the problem B Dirty reading problem ？ By adding a read lock （S lock ） Do you ？  This is actually two concurrent transactions , One to read , One to write , That caused this problem .

How to solve dirty writing ？ How to add the lock ？ How does dirty reading come about ?

At this time, the transaction corresponding to the write operation adds S lock , So at this point , Other concurrent transactions cannot be written ？？？

I just added S lock , In this case , Any other transaction can read this data at any time , Because you can get it at will S lock , This causes dirty reading . 

3.Read  Commit： This level solves the problem of dirty reading （ By adding S Lock resolved ？？？）, But there are still problems , That's it It can't be read repeatedly The problem of . Business A To update the data , Another concurrent transaction B Read the data before updating , And then in business A After submission , Then read the data , Business B The two readings are inconsistent , This is a non repeatable question . How to solve ？？？ By adding a read lock （S lock ） Do you ？  This is actually two concurrent transactions , One to read , One to write , That caused this problem .

How to solve the dirty reading problem ？

Read transactions , stay The moment of reading With a reading lock （S lock ）, Release immediately after reading , So you can't write while reading ; Write the whole transaction X lock , In this way, during the whole execution of the write transaction , You can't read anything else , Prevents other transactions from reading uncommitted data , This solves the dirty reading problem .  Both reading and writing work together to prevent dirty reading .

Why can there be non repeatable reading and unreal reading ？ 

4.Repeatable Read:  Solved the problem of non repeatable reading （ By adding S Lock implementation ？？？？）, But this level still has Fantasy reading The problem of . Business A To add a piece of data , Concurrent transactions B stay A This data is not read before adding , Then transaction A Add this data , Then transaction B Read this data , This data is important to the transaction B Come on , Just suddenly appeared , This is called Unreal reading . Another explanation , Business B Empty the watch , Then transaction A Insert another piece of data , Then transaction B It is found that there is data in the table , Cause unreal reading . How to solve ？？？ By adding a read lock （S lock ） Do you ？   This is actually two concurrent transactions , One to read , One to write , That caused this problem .

How to solve the problem of unrepeatable reading ？

Read the whole time to add read lock （S lock ）, In this case , In the course of the whole transaction , Any other transaction cannot be written , In this case , It can ensure that the data read twice is consistent . Yes, of course , Write operation should be locked , Otherwise, any transaction can be written .

5. Serialization （Serializable）： It can solve the problem of unreal reading , By adding a write lock （X lock ） The way , It is to add... Directly to the operation record X lock , Serialization is realized . But this makes the transaction execute serially , Greatly reduce the concurrency performance .

Why does unreal reading appear ？

Because the previous locks are row locks , All operations are for one row of data , The problem of unreal reading should focus on the whole table , Not a specific line , Such as transaction A Empty a table , The whole table is operated , Not a specific line , At this time, row locks are meaningless for the operation of the entire table , Concurrent transactions B Can be unrestricted （ It is definitely not restricted by row lock , Because I want to insert a new line , Where did you get the row lock ？？？） Insert a piece of data randomly , This creates unreal reading .

How to solve unreal reading ？

While reading , Add read lock to the whole table （S lock ）

At the time of writing , Write lock on the whole table （X lock ）

A small summary ： Dirty reading 、 It can't be read repeatedly 、 Fantasy reading , Because of the concurrent transaction , A transaction writes data , A data to read data , Dirty reads and unrepeatable reads are operations specific to a specific row , So we need to add a row lock ; Phantom reading is an operation on the whole table , So you need to add a watch lock .

Other knowledge points ：

The transaction ACID： 

Read the following two articles carefully ：

Mysql Of select Lock analysis - wintersoft - Blog Garden

【 original 】MySQL(Innodb) The principle of indexing - Lonely smoke - Blog Garden