MVCC (Multi-Version Concurrent Control, that is, multi-version Concurrent Control)
Each record generates a version chain to solve the isolation level of the transaction.
Each record has two hidden columns, trx_id: transaction ID and a pointer to the previous version of the record.
Such as: Mysql default Repeated Read
Purpose: To ensure the consistency of reading data twice in the same transaction.
Transaction A generates a ReadView when reading data for the first time, recording the collection of currently active transactions. When reading the data again, it will determine which version of the record is invisible, and take the first visible version of the record and return it as the record value.
The judgment is based on the collection of activities recorded by ReadView. If a version of trx_id is in the collection, it is not visible. It is not visible if it is larger than the maximum. Visible if it is less than the smallest trx_id in the set. Because trx_id is incremented, it is smaller than trx_id in the active transaction, indicating that the transaction that generated the record was committed before transaction A first read and generated ReadView. This ensures that the data read twice is consistent.
Equivalent to a snapshot, a snapshot is generated during the first read, and transactions that have been created at this moment or transactions created after the second are not visible to the data. Filter by transaction ID.
MVCC is to solve the isolation level related to dirty reads and non-repeatable reads. ReadView is generated only when reading. Update, Insert, etc. are not generated.
The usual select, update, insert and other statements are transactions. When executing a statement, mysql will automatically open the transaction and automatically commit after execution. You can check whether auto commit is enabled by show variables LIKE 'autocommit'. https://blog.csdn.net/wx145/article/details/82740737
Each statement is a transaction, the trx_id will continue to increase, and it will return to zero when it reaches the maximum. At that moment, there will be problems such as dirty reading, but it will take decades to reach the maximum value. When the self-incrementing primary key reaches the limit, it will not return to zero. If it is created again, the maximum value will be inserted and the primary key conflict will be reported. https://www.cnblogs.com/gaosf/p/11189127.html
verification:
1. Session 1 starts the transaction:
Transaction ID: an active transaction:
2. Session 2 starts another transaction:
Generate another active transaction:
3. Transaction 2 performs the insert operation:
4. Transaction 2 query:
5: Transaction 1 query:
6. Transaction 1 modification: blocking at this time because transaction 2 has not yet been committed. Overtime will report timeout.
7. Transaction 2 commit
Only one active transaction remains from session 1 or session 2
8. Session 1 query. At this point, it can be seen that mysql's MVCC prevents magic reading. There is only one record for multiple reads, and the results are consistent.
9. Session 1 is updated, and the record inserted in session 2 is recorded.
10. Session 1 query: There has been a phantom read.
The ninth step due to the modification of the new record, resulting in the latest version of the record trx_id is the id of the current transaction, the version of the current transaction is visible, so the otherwise invisible becomes visible again.
Although MVCC in normal scenes can prevent phantom reading, this extreme scene alone cannot prevent phantom reading by MVCC alone.