MySQL transaction isolation level

One 、ACID attribute

• Atomicity (Atomicity)： A transaction is an atomic operation , Or all of them can be executed successfully , Or the execution fails together
• Uniformity (Consistent)： The beginning and end of a transaction , The data must be consistent
• Isolation, (Isolation): In the process of transaction processing, it is necessary to ensure mutual isolation 、 Independent
• persistence (Durale): When the business is over , Modifications to the data are permanently saved

Two 、 Problems caused by concurrent transaction processing

Update missing (Lost Update) or Dirty write : Multiple transactions without knowing that other transactions exist , At the same time, modify the data , Dirty writing will appear .
The last update covers the updates made by other firms

Dirty reading (Dirty Reads): When a transaction reads a record and modifies others , But it hasn't been submitted yet , At this point, another transaction also reads , If not controlled , The data read by the second transaction is dirty data .
Business A Read to transaction B Data that has been modified but not yet submitted

Non repeatability (Non-Repeatable Reads): Some time after a transaction reads some data , Read the previously read data again , But found that the data it read out has changed .
Business A The results of the same internal query statement read at different times are inconsistent , Nonconformance isolation

Fantasy reading (Phantom Reads):   A transaction reads previously retrieved data according to the same query criteria , However, it is found that other transactions have inserted new data satisfying their query criteria .
Business A Read the business B New data submitted , Nonconformance isolation

3、 ... and 、 Isolation level  

  Dirty reading 、 It can't be read repeatedly 、 Fantasy reading , In fact, it's all about database read consistency , The database must provide some transaction isolation mechanism to solve , and MySQL The default is repeatable reading .

Isolation level	Dirty reading	It can't be read repeatedly	Fantasy reading
Read uncommitted	YES	YES	YES
Read submitted	NO	YES	YES
Repeatable	NO	NO	YES
Serialization	NO	NO	NO

Read uncommitted ： Business A Updated data ( Has not been submitted ), And the business B But you can find the transaction A Updated data
Read submitted : Business A Updated data ( Has not been submitted ), Business B Cannot query transaction A Updated data ( Solved the problem of dirty reading )
Repeatable degrees : Business A Checked the records ( If 400), Business B Changed data (400 - 50 = 350, then commit), Business A The value read again before committing the transaction is still 400, Until transaction A The latest updated data can only be read after the transaction is committed ( It ensures the isolation between transactions )
Serialization : Data with row lock , Other transactions cannot be added, deleted, modified or queried , It's like an exclusive lock

  Four 、 Locking mechanism

A lock is a computer that coordinates multiple processes / The mechanism by which threads access a resource concurrently , Lock classification ：
From the performance of the database

1. Optimism lock ( Version number comparison )
2. Pessimistic locking

From the type of database operation

1. Read the lock ( Shared lock , Multiple read operations can be performed simultaneously without affecting each other )
2. Write lock ( Exclusive lock , Before the operation is completed , Nothing else can be done , Ensure serial connection )

Granularity of database operations from heap

1. Table locks
2. Row lock

Table locks
Lock the whole table with each operation , Low overhead , Locked fast , A deadlock will not occur , Big lock size , The probability of lock conflict is higher , Concurrent reads are the lowest , Generally used in data migration scenarios .

Row lock
Lock one row of data per operation , Spending big , Lock the slow , A deadlock occurs , The lock granularity is the smallest , The lowest probability of lock collisions ,InnoDB Support transactions and row locks , however MylSAM I won't support it .
One session Enable transaction updates without committing , Another one session Updating the same record will block , Updating different records will not block .

Clearance lock
Lock is the gap between two values .
Gap lock can solve the unreal reading problem in some cases
The gap lock will only take effect at the repeatable read isolation level

update account set name = '100' where id > 8 and id < 18;
 other Session It is impossible to lock all the row records contained in this range and the gap row records within this range 
 Insert or modify any data in the gap of the original table . namely id stay (3,20] Data cannot be modified in any interval , Be careful 
 The last one 20 Also included .

for example SQL: : There is a gap id by (3,10),(10,20),(20, It's just infinite ) These three intervals

Temporary lock
Combination of row lock and clearance lock
The key lock is mainly female in order to avoid unreal reading , If the transaction is downgraded to read committed , The keyless lock will fail .
for example ： Example of clearance lock above SQL, Gap is (3,20] The whole range

Lockless pilot lock will be upgraded to table lock

The lock is mainly added to the index , If the non lock field is updated , Row locks may become table locks
for example : If now there will be no index char Change the type field to another varchar type , Because there is no index , The full table will be scanned , Finally upgrade to ' Table locks '​​​​​​​

Lock optimization suggestions

1. ​​​​​​​ Try to make all data retrieval complete through index , Avoid upgrading non indexed row locks to table locks
2. Design index reasonably , Minimize the scope of the lock
3. Minimize the range of search conditions , Avoid gap locks
4. Try to control the transaction size , Reduce the amount of locked resources and the length of time , Involving transaction locking SQL Try to put it at the end of the transaction
5. As low level transaction isolation as possible