One, undo log version chain
When we execute update, insert, delete, undo log will be generated to prevent rollback.
An SQL execution will generate an undo log log:
Among them, trx_id is the transaction id that executes this sql, roll_pointer points to the undo log log modified to the same value, because there is no current, it points to an empty object.
There is another SQL to modify this data, the transaction id is 51, and the value is changed to B:
Modify the same piece of data and connect it through roll_pointer to form an undo log version chain.
Second, the ReadView mechanism
When a transaction is executed, a ReadView is generated. The ReadView includes:
1.m_ids: transaction id not yet submitted
2.min_trx_id: the smallest transaction id in m_ids
3.max_trx_id: the next transaction id generated by mysql
4.creator_trx_id: the current transaction id, which is the transaction id that created this Read View
For example, there are now transaction A and transaction B to modify the data, and the read view generated by transaction A:
Three, MySQL's RR level implementation principle
So how to implement mysql MVCC mechanism based on undo log version chain and ReadView?
Let's take a look at the default RR level of MySQL, which solves the problems of dirty reading, non-repeatable reading, and phantom reading:
Dirty read: Transaction B is started and undo log generates a log. At this time, transaction A comes to query, the undo log with value B, trx_id is 60, which is larger than the creator_trx_id: 50 of ReadView in transaction A, indicating that it was executed before transaction A started. Explain that this transaction and transaction A are going on at the same time and continue to go down. The trx_id of the next log is 50, that is, the id of your transaction can be queried, and the return value is A. This solves the problem of dirty reading.
Non-repeatable read: Before transaction B starts, the value queried by transaction A is A. After submission, the value queried by transaction A is still A, which solves the problem of non-repeatable read.
Phantom reading: for example, to execute a sql: select count (*) where id> 10;
When transaction A first started querying, only three items met the conditions. Transaction B now inserts a piece of data with id 6. Transaction A is used to query the data with id> 10. It is found that there are 2 compound query conditions, one is the original 3, and the other is 4 after the transaction B is submitted. Transaction A has a smaller trx_id than transaction B, and it is in m_ids, so the original data returned is still 3. This solves the problem of phantom reading.