MySQL transaction characteristics and implementation principle

MySQL Business details

What is business

Simply speaking , A transaction is a logical set of operations , Or do it all , Or all failed .

Take a chestnut ： The most common example of a transaction is a transfer . If Xiaohong wants to transfer to Xiaoming 1000 element , Transfer involves two key steps ：

• Xiaohong's account decreases 1000 element .
• Xiao Ming's account has increased 100 element .

Transactions treat these two operations as logical ones A whole , Or the operations included in the whole are successful , Or they all failed . In this way, the balance of Xiaohong account will not decrease , The balance of the small name account has not increased .

Four characteristics of transactions （ACID）

Relational database （ for example ：MySQL、SQL Server、Oracle etc. ） Everything has ACID characteristic ：

1. Atomicity （Atomicity）： Transaction is the smallest execution unit and cannot be split . The atomicity of the transaction ensures that the actions either all succeed , Or fail to roll back .
2. Uniformity （Consistency）： Before and after the transaction , Data consistency . For example, transfer business , Whether the operation is successful or not , The total amount of the account of the transferor and the payee is the same .
3. Isolation, （Isolation）： When multiple transactions access the database concurrently , One transaction is not affected by other transactions , The database is independent between concurrent transactions .
4. persistence （Durability）： After a transaction is committed , Changes to the data in the database are persistent , Even if the database fails, it will not have any impact on it .

The isolation level of the transaction

Problems caused by concurrent transactions

• Dirty reading ： When a transaction is accessing data and modifying the data , This modification has not yet been committed to the database , At this time, another transaction also accesses the data , And then I used this data . Because this data is not submitted yet , So the data read by another transaction is “ Dirty data ”, basis “ Dirty data ” The operation may not be correct .
• It can't be read repeatedly ： Reading the same data multiple times in a transaction . Before the end of the business , Another transaction also accesses the data . that , Between two reads in the first transaction , Due to the modification of the second transaction, the data read by the first transaction twice may be different . This happens when the data read twice in a transaction is different , So it's called unrepeatable reading .
• Fantasy reading ： Unreal reading is similar to nonrepeatable reading . It happens in a transaction （T1） Read a few lines of data , Then another concurrent transaction （T2） When some data is inserted . In the subsequent query , The first thing （T1） There will be more records that don't exist , It's like an illusion , So it's called Unreal reading .
• Missing changes ： When a transaction reads a data , Another transaction also accesses the data , After modifying the data in the first transaction , The second transaction also modifies the data . In this way, the modification result in the first transaction will be lost , So it's called lost modification . for example ： Business 1 Read data from a table A=20, Business 2 Also read A=20, Business 1 modify A=A-1, Business 2 Also modify A=A-1, final result A=19, Business 1 The modification of is lost .

The isolation level of the transaction

• READ-UNCOMMITTED( Read uncommitted )： Lowest isolation level , Allow read of uncommitted data changes , Can cause dirty reading 、 Phantom or unrepeatable reading .
• READ-COMMITTED( Read committed )： Allow to read data submitted by concurrent transactions , Can prevent dirty reading , But phantom or unrepeatable reads can still occur .
• REPEATABLE-READ( Repeatable )： Multiple reads of the same field are consistent , Unless the data is modified by the transaction itself , Can prevent dirty and unrepeatable read , But phantom reading can still happen .
• SERIALIZABLE( Serializable ) Highest isolation level , Completely obey ACID Isolation level . All transactions are executed one by one , In this way, there is no interference between transactions , in other words , This level prevents dirty reads 、 Unrepeatable reading and phantom reading .

Isolation level	Dirty reading	It can't be read repeatedly	Fantasy reading
READ-UNCOMMITTED
READ-COMMITTED	x
REPEATABLE-READ	x	x
SERIALIZABLE	x	x	x

MySQL What is the default isolation level for

MySQL InnoDB The default isolation level supported by the storage engine is REPEATABLE-READ（ Can be reread ）. We can go through SELECT @@tx_isolation; Order to see ,MySQL 8.0 The order was changed to SELECT @@transaction_isolation;

Because the lower the isolation level , The fewer locks the transaction requests , So the isolation level of most database systems is READ-COMMITTED( Read submissions ) , But what you need to know is InnoDB The storage engine uses... By default REPEATABLE-READ（ Can be reread ） There will be no loss of performance .

InnoDB Storage engine in Distributed transactions In general, we use SERIALIZABLE( Serializable ) Isolation level .

The principle of transaction implementation

• A Atomicity is caused by undo log（ Rollback log ） Log guarantees , It records the log information that needs to be rolled back , When the transaction is rolled back, undo the successfully executed sql.

• C Consistency is guaranteed by three other features 、 The program code should ensure business consistency

• I Isolation by MVCC To guarantee .

• D Persistence is made up of memory +redo log（ Redo log ） To guarantee ,mysql Modify data both in memory and redo log Record this operation , When it goes down, you can start from redo log recovery .

InnoDB redo log Writing disk ,InnoDB Affairs enter prepare state . If the previous prepare success ,binlog Writing disk , Continue to persist the transaction log to binlog, If persistence succeeds , that InnoDB Business goes into commit state ( stay redo log There's a commit Record ).

redolog The disk will be swiped when the system is idle .

What is? MVCC

Multi version concurrency control ： When reading data, the data is saved in a snapshot like way , In this way, the read lock does not conflict with the write lock , Different things session You'll see your own version of the data , Version chain .

MVCC The realization of depends on ： Hide fields 、Read View、undo log. In internal implementation ,InnoDB Through... Of data rows DB_TRX_ID and Read View To determine the visibility of the data , If not visible , Through the... Of the data line DB_ROLL_PTR find undo log Historical version in . The data version read by each transaction may be different , In the same transaction , The user can only see the transaction created Read View The changes that have been committed before and the changes made by the transaction itself .

In the internal ,InnoDB Storage engine , Three hidden fields have been added for each row of fields .

• DB_TRX_ID： Represents the last transaction to insert or update this row id.delete Operations are treated internally as updates , Just in the record header Record Header Record the deleted_flag Mark it as deleted .

• DB_ROLL_PTR： rollback pointer . Point to the line undo log, If not updated , Is empty .

• DB_ROW_ID： If the primary key is not set and the table does not create a unique non empty index ,InnoDB I can use it id To generate a clustered index .

Read View

class ReadView {
    
  /* ... */
private:
  trx_id_t m_low_limit_id;      /*  Greater than or equal to this  ID  All transactions are invisible  */

  trx_id_t m_up_limit_id;       /*  Less than this  ID  All transactions are visible  */

  trx_id_t m_creator_trx_id;    /*  Create the  Read View  The business of ID */

  trx_id_t m_low_limit_no;      /*  Business  Number,  Less than it should be  Number  Of  Undo Logs  Can be  Purge */

  ids_t m_ids;                  /*  establish  Read View  List of active transactions at  */

  m_closed;                     /*  Mark  Read View  whether  close */
}

Read View It is mainly used for visibility judgment , It's preserved “ Other active transactions that are not currently visible to this transaction ”.

m_low_limit_id： The biggest thing that has ever happened ID+1, The next transaction to be assigned ID. Greater than or equal to this ID All data versions are not visible .

m_up_limit_id： Active transaction list m_ids The smallest transaction in ID, If m_ids It's empty , be m_up_limit_id by m_low_limit_id. Less than this ID All data versions are visible .

m_ids：Read View Other uncommitted active transactions at creation time ID list . establish Read View when , The current uncommitted transaction ID recorded , Later, even if they change the value of the record row , It is also invisible to the current transaction .m_ids Does not include the current transaction and the committed transaction （ In memory ）.

m_creator_trx_id： Create the Read View The business of ID.

Data visibility

stay InnoDB In the storage engine , After creating a new transaction , Execute each select Statement before , Will create a snapshot （Read View）, The snapshot saves the active data in the current database system （ No, commit） Of business ID Number . In fact, it simply saves other transactions in the system that should not be seen by this transaction at present ID list （ namely m_ids）. When the user wants to read a record row in this transaction ,InnoDB This record line will be DB_TRX_ID And Read View Some variables in and the current transaction ID Compare , Determine if visibility conditions are met .

1. Create when starting a transaction readview,readView Maintain the currently active transaction id, That is, uncommitted transactions id, Sorting generates an array .
2. Access data , Get transactions in data id（ Get the transaction id The biggest record ）, contrast readview.
3. If in readview Left side （ Than readview All small ）, You can visit （ On the left means that the transaction has been committed ）.
4. If in readview To the right of （ Than readview All big ） Or right here readview in , No access , obtain roll_pointer, Take the previous version and compare it again （ On the right means , The transaction is in readview After generation , stay readview This means that the transaction has not been committed ）.

This is it. Mysql Of MVCC, Through the version chain , Implement multiple versions , Can be read concurrently - Write , Write - read . adopt ReadView Different implementations of the generation policy have different isolation levels .

The difference between committed reads and repeatable reads is that they generate ReadView The strategy is different .

At the transaction isolation level RC and RR （InnoDB The default transaction isolation level for the storage engine ） Next ,InnoDB Storage engine use MVCC（ Non lock consistent read ）, But they generate Read View The timing is different

• stay RC Under isolation level Every time select Generate a before the query Read View (m_ids list )
• stay RR At the isolation level, only after the transaction starts for the first time select Generate a... Before data Read View（m_ids list ）