I have a question about MVCC in MySQL.
The steps MySQL takes to update a row are as follows:
1.Acquire an exclusive lock.
2.First write to the undo log: record the pre-update data in the undo log and generate a pointer to the record in the undo log.
3.Then update the row: modify the transaction ID, modify the rollback pointer in the clustered index row, and change the data.
4.Write to the redo log: record the transaction ID, the rollback pointer, and the changes made to the data.
Then, online resources mention that MVCC is lock-free and achieves this through version chain lookup, where the starting point of the version chain is the row in the clustered index.
When reading, I first need to locate the row and check the transaction ID to see if it is visible in the read view.
If a read operation finds that this transaction ID is visible and then prepares to read the row, but another write operation with a higher transaction ID modifies the row, and the read operation does not lock, won’t the read operation possibly read a partially modified row?
Is My Understanding of MySQL’s MVCC Correct?
kimasu ji is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.