MySQL transaction isolation level and mvcc

MVCC English full name Multi-Version Concurrency Control, Translation into Chinese means Multi version concurrency control . Achieve non blocking concurrent access . The principle is similar 《Java Inside CAS Realization principle 》 Who is like who? Maybe we can learn by analogy

• Transaction isolation level
  Dirty write ： One transaction modifies the modified data of another uncommitted transaction , That is to say, when the area modifies the uncommitted part of others, the modification will no longer exist when rolling back .
  Dirty reading ： One transaction reads data modified by another uncommitted transaction , During the same rollback, a non-existent data is read ,
  It can't be read repeatedly ： That is to say, when a transaction is not committed, another data is read , After reading, the data is modified by another transaction , When the uncommitted transaction reads the data again, it is different from the previous one . This leads to non repeatable reading , The values read multiple times in the same transaction are different .
  Fantasy reading ： Similar to nonrepeatable reading , However, the number of records read twice is different , Suddenly appear like a phantom .
  SQL The standard isolation levels are as follows ：

Isolation level	name	Dirty reading	It can't be read repeatedly	Fantasy reading
READ UNCOMMITTED	Uncommitted read	Possible	Possible	Possible
READ COMMITTED	Read committed	Not Possible	Possible	Possible
REPEATABLE READ	Repeatable	Not Possible	Not Possible	Possible
SERIALIZABLE	Serializable	Not Possible	Not Possible	Not Possible

There is no dirty writing because , Dirty writes are not allowed at all isolation levels .

• MySQL Isolation level
  Different databases support standards SQL The isolation level of is different ,MySQL All four isolation levels support , And MySQL The default isolation level for is REPEATABLE READ, We can manually modify the isolation level of transactions . and MySQL stay REPEATABLE READ Under isolation level , It can prohibit the occurrence of unreal reading problems .
  1、 Use READ UNCOMMITTED Isolation level transactions , Because you can read the modified records of uncommitted transactions , So just read the latest version of the record
  2、 For the use of SERIALIZABLE For isolation level transactions , The designer specifies to access the records by locking
  3、 For the use of READ COMMITTED and REPEATABLE READ For isolation level transactions , You must ensure that you read the transaction modified records that have been committed , That is, if another transaction has modified the record but has not yet committed , You can't read the latest version of the record directly , The core issue is ： You need to determine which version in the version chain is visible to the current transaction ,
• readview
  readview Save the currently active read / write transactions ID、 The smallest transaction currently active ID、 The next transaction to be generated ID（ Predict by the global variable that generated the transaction ）、 Generate this readview The business of ID. With this readview, When you want to access a record, first judge that there is a transaction in the hidden column of the record ID, That is, modify the transaction of the record ID, If less than and not active readview Active list in , It indicates that the transaction has been committed and can be accessed directly , If it is still in the active list, it means that it is still active and can not be read. Otherwise, it will Dirty reading . If it is greater than, it means that readview The transactions generated after are inaccessible, or they will occur Can't read repeatedly or unreasonably . When it is inaccessible, the rollback pointer in the hidden column will be obtained to find undo The logs are then compared until they are accessible or until the end of the version chain .《 What is the version chain 》
• RC and RR Different implementations of isolation levels
  READ COMMITTED —— Generate a... Before each read ReadView
  That is, if there are multiple read operations in the transaction , Each read generates a ReadView snapshot , That is to say, the last time it was read ReadView It may not be the same as this reading , So you may read a different version, that is Can't read repeatedly or unreasonably
  REPEATABLE READ —— Generate a... When reading data for the first time ReadView
  That is, once the transaction starts , The first query is the same as several queries in the same transaction ReadView, That is, the version freeze frame snapshot starts the transaction , The version read every time in the future is the same , That is, it will not happen Can't read repeatedly or unreasonably
  Dirty reading is impossible , Because both reads are unreadable in the transaction active version , That is, only the version of the committed transaction can be read . So it's impossible to dirty read .

The principle is similar 《Java Inside CAS Realization principle 》 Who is like who? Maybe we can learn by analogy

• reflection
  Will find MVCC Good! , No jam , But the discovery only solves the problem of reading , Writing cannot guarantee , How to avoid dirty writing , Of course, it comes by way of a lock , Before modifying a record, lock it and do not modify other transactions, that is, dirty writes will not occur . There's another problem , What to do when a business needs to read the latest value every time MVCC What you read may be an old version , Of course, this requirement is also solved by locking the read and write . There is also the understanding that one is , There is no lock in the normal query tone , Unless you explicitly write lock , A lock will be added in the writing tone without other statements to ensure that dirty locks will not occur ,,,, Details of the lock
  Transferred to 《MySQL—— Brief description of locking mechanism 》