MySQL 45 | 08 is the transaction isolated or not?

08 | Is the transaction isolated or not ？

• stay Repeatable Transactions executed at the isolation level , Not affected by the outside world . Even if there are other transactions that modify the data , Business T What I see is still the same as what I saw when I started .
• Row lock When , A transaction needs to update a row , If there is another A transaction has the row lock of this row , It will be locked , Enter the waiting state .

problem ： Then wait until the transaction obtains the row lock to update the data , What is the value it reads ？

Example ： t(id, k) —> (1,1)

• chart 1 Business A、B、C The implementation process of :

• Note the start time of the transaction .

begin/start transaction Command is not the starting point of a transaction , After implementing them The first operation after InnoDB surface The sentence of , The business really starts .

to want to Start now A business , have access to start transaction with consistent snapshot This command .

• Business C Not explicitly used begin/commit, Express this update Statement itself is a transaction , When the statement is completed Automatic submission .

• Business B Query after the row has been updated .

• Business A In a Read only transactions Query in , And chronologically, it's in transactions B After the query of .

The result is ： Business B Checked up k The value of is 3, And the business A Checked up k The value of is 1 .

Two “ View ”

• view. It's a Virtual table defined with query statement , Execute the query statement at the time of the call and generate the result . The syntax for creating a view is create view…, And its query method is the same as the table .
• InnoDB In the realization of MVCC Used in Consistent read view , namely consistent read view, Used to support RC（Read Committed, Read the submission ） and RR（Repeatable Read, Repeatable ） Implementation of isolation level .

“ snapshot ” stay MVCC How does Li work ？

• stay Repeatable Under isolation level , When the transaction starts “ Took a snapshot ”. This snapshot is based on the entire library .

problem ： How is the snapshot implemented ?

In the data sheet A line of records , In fact, there may be Multiple versions (row), Each version has its own rowtrx_id.

• Pictured 2 Shown , It is the state of a record that is continuously updated by multiple transactions .

• The dotted line in the figure shows the same line of data 4 A version , The latest version is V4,k The value of is 22, It is be transaction id by 25 Transaction update of , So it's rowtrx_id It's also 25.

• Statement update generates undo log（ Rollback log ）, Three dashed arrows , Namely undo log .

• and V1、V2、V3 It's not physically real , It's based on the current version and undo log Work it out Of .

Consistency view （read-view）

• InnoDB For each transaction, a Array , Used to save the transaction startup moment , Right now “ live jump ” All the business of ID （ Launched but not yet submitted ） .

• Transactions in the array ID The minimum value of is recorded as Low water level , Transactions that have been created in the current system ID The maximum of Add 1 Write it down as premium position .

• This view array and high water level , It makes up the consistency view of the current transaction （read-view）.

• Data version Visibility rules , It's data-based rowtrx_id And this Consistency view Of contrast resulting .

  • Data version visibility rules

  

  • For the moment the current transaction starts , A data version of rowtrx_id, There are several possibilities ：
    • It falls on the green part , Indicates that this version is Committed transactions Or is it The current transaction generates itself Of , The data is Visible ;
    • It falls on the red part , Indicates that this version is made by Transaction generation to be started in the future Of , Yes Invisible ;
    • It falls on the yellow part , There are two situations
      • a. if rowtrx_id In the array , Indicates that this version is made by It hasn't been submitted yet Generated by the transaction of , invisible ;
      • b. if rowtrx_id Not in array , Indicates that this version is Submitted Generated by the transaction of , so .

• InnoDB Take advantage of “ There are multiple versions of all the data ” This characteristic of , Realized “ Second level creation snapshot ” The ability of .

Continue to look at the figure below 1 Three things in , Analyze the business A The result returned by the statement of , Why k=1 ?

• here , Let's make the following assumptions ：

  1. Business A Prior to the start , There is only one active transaction in the system ID yes 99;
  2. Business A、B、C The version numbers of are 100、101、102, And there are only four transactions in the current system ;
  3. Before three things begin ,(1,1） This line of data rowtrx_id yes 90.

• such , Business A The view array of is [99,100], Business B The array of views for is [99,100,101], Business C The array of views for is [99,100,101,102].

• Business A Query data logic diagram

• The first valid update is Business C, The data from (1,1) Changed to (1,2). Now , The most important part of this data The new version of the rowtrx_id yes 102, and 90 This version has become a historical version .

• The second valid update is Business B, The data from (1,2) Changed to (1,3). Now , The latest version of this data （ namely row trx_id） yes 101, and 102 It's a historical version again .

• stay Business A When querying , In fact, the business B Not yet submitted , But it produces (1,3) This version has It has become the current version . But this version of transaction A It has to be invisible , Otherwise it will become dirty reading .

  • Business A The data reading process of query statements is like this ： Its view array is [99,100]
    • find (1,3) When , Determine the rowtrx_id=101, It's bigger than the high water level , In the red zone , invisible ;
    • next , Find the last historical version , Take a look rowtrx_id=102, It's bigger than the high water level , In the red zone , invisible ;
    • Look forward to , Finally found （1,1), its rowtrx_id=90, Less than the low water level , In the Green Zone , so .

• This is how it works , Although this row of data has been modified during the period , But the business A Whenever you look up , See this line of data The results are consistent , So we call it Read consistency .

• A data version , For a transaction view , In addition to their own updates are always visible Outside , There are three situations ：

• edition not Submit , invisible ;

• edition has Submit , But in view creation after The submitted , invisible ;

• edition has Submit , And it is created in the view front The submitted , so .

Update logic

doubt ： Business B Of update sentence , If you read according to consistency , It seems that the result is wrong ？

Business B The view array of is generated first , After that C To submit , It's not supposed to be invisible (1,2) Do you , How can Work out (1,3) Come on ?

• Business B Update the logic diagram

• If the transaction B stay Query before updating One time data , This query returns k It's worth it yes 1.
• however , When it's going Update data When , You can't update the historical version anymore , Otherwise, the transaction C The update of was lost . therefore , Business B At this time set k=k+1 Is in （1,2） Based on the operation of .

** The rules ： The updated data are First learns to write Of , And this read , You can only read the current value , be called “ The current reading ”（current read）. **

• therefore , At the time of the update , The current reading The data is (1,2), After the update, a new version of the data is generated (1,3), This new version Of rowtrx_id yes 101.
• therefore , In execution Business B Query statement When , Take a look at their own version number is 101, The version number of the latest data is also 101, yes My own update , You can use it directly , therefore Inquire about Got k The value of is 3.

except update Out of statement ,select Statement if Lock , It's also The current reading .

• therefore , If the business A Query statement select *fromt where id=1 Revise it , add lock in share mode or for update, You can also read that the version number is 101 The data of , Back to k The value of is 3.

• The next two select sentence , Namely They added Read the lock （S lock , Shared lock ） and Write lock （X lock , Exclusive lock ）.

mysql> select k from t where id=1 lock in share mode;
mysql> select k from t where id=1 for update;

What if C It wasn't submitted immediately , It becomes the following business C’, What will happen ？

• Business A、B、C’ The implementation process of :

Business C’ The difference is that the , The update was not submitted immediately , Before it's submitted , Business B The update statement of is initiated first .

• Although the business C’ also Not submitted , however (1,2) This Version has also been generated 了 , And it's current The latest version . that , things service B Of to update What will the statement do ？

• Now , As mentioned in the previous article “ Two stage lock protocol ” We're going to play . Business C’ Not submitted , in other words (1,2) On this version The lock hasn't been released yet . And the business B yes The current reading , You have to read the latest version , And it has to be locked , So Locked up 了 , must Wait for business C’ Release the lock , In order to continue its current reading .

• Business B Update the logic diagram （ Cooperate with the business C’）

• Come here , Read consistency 、 The current read and row locks are linked .

Back to the question at the beginning ： How is the ability to reread transactions possible ？

• Repeatable The core of Read consistency （consistent read）;

• and Transaction update Data time , Only use The current reading .

• If the current record Row locks are occupied by other transactions Words , You need to enter Lock wait .

Read the submission Logic and Repeatable The logic of is similar to , The main difference between them is ：

• stay Repeatable Under isolation level , Just create it at the beginning of the transaction Consistency view , Later in the business Other queries share this consistent view ;
• stay Read the submission Under isolation level , Every sentence Before execution Metropolis Recalculate a new view .

stay Read the submission Under isolation level , Business A And transaction B The query statement of k, They should be How many? ？

• “start transaction with consistent snapshot; ” It means Start with this statement , Create a consistent snapshot of the entire transaction . therefore , stay Read the submission Under isolation level , This usage is meaningless , Equivalent to ordinary Of start transaction

• Read the state diagram when submitting ：

• You can see the The timing of creating the view array has changed , It's the picture Medium read view box .（ Be careful ： here , We still use business C The logic of direct submission , Not business C’）

• At this time , Business A Of View array of query statements Is in When executing this statement, create Of , In time sequence **(1,2)、(1,3) Generation The time is when the view array is created Before **. however , At this moment ：

• (1,3) It hasn't been submitted yet , Belong to the situation 1, invisible ;

• (1,2) Submit 了 , Belong to the situation 3, so .

• therefore , Now Business A The query statement returns k=2. apparently , Business B Query results k=3.

Summary

• InnoDB The row data of Multiple versions , Each data version has its own rowtrx_id

• Each transaction or statement has its own One Consistency view

• Common query The sentence is Read consistency , Consistent reading will be based on rowtrx_id And consistency view to determine the visibility of the data version .

  • about Repeatable , The query only acknowledges that Business The completed data has been submitted before startup ;
  • about Read the submission , The query only acknowledges that sentence The completed data has been submitted before startup ;

• The current reading , Always read Submitted Accomplished The latest version .