Concepts of dirty read, phantom read, and unrepeatable read
- Dirty read: a transaction accesses uncommitted data from another transaction. When a transaction is accessing data and making changes to the data that have not yet been committed to the database, another transaction also accesses the data and then consumes it.
- Non-repeatable read: a transaction queries the same record twice and gets inconsistent results. Read the same data multiple times within a transaction. The same data is accessed by another transaction while the transaction is still active. Then, between the two reads in the first transaction, the data read in the first transaction may not be the same because of the modification in the second transaction. This happens when the data read twice in a transaction is not the same and is therefore called a non-repeatable read.
- Unreal read: a transaction is queried twice, and the number of records obtained is inconsistent. Phantom reading is a special case of unrepeatable reading. The first transaction adds or removes corresponding data in the interval between the first and second queries, and the first transaction does not have the same number of queries, as if in an illusion.
Transaction isolation level
- Read Uncommitted is when changes made by a transaction can be seen by other transactions before a transaction has committed. Generally speaking, someone else’s transaction to change data has not been committed, and I can read it in my transaction.
- Read Committed means that after a transaction is committed, the changes it makes can only be seen by other transactions. In layman’s terms, someone else’s transaction has been committed and I can only read it in my transaction.
- Repeatable read means that the data seen during the execution of a transaction is always the same as the data seen when the transaction is started. Of course, at the repeatable read isolation level, uncommitted changes are also invisible to other transactions. In layman’s terms, someone else’s transaction has been committed and I don’t read it in my transaction. The MySQL InnoDB storage engine supports an isolation level of repeatable reads by default.
- Serializable, as the name implies, is that for the same row, “write” will add “write lock”, “read” will add “read lock”. When a read-write lock conflict occurs, the last accessed transaction must wait for the previous transaction to complete before execution can continue. In plain English, if my transaction has not been committed, no one else can change the data.
- If the isolation level is“Read uncommitted”,
V1
The value of PI is 2. Transaction B has not committed yet, but the result has already been seen by A. soV2, V3
They’re both 2’s. - If the isolation level is“Read submit”,
V1
Is 1,V2
The value of theta is 2. Transaction B’s updates are not seen by A until they are committed. So,V3
The value of PI is also 2. - If the isolation level is“Repeatable”,
V1, V2,
Is 1,V3
Is 2. The reasonV2
1, which follows the requirement that the data seen by the transaction during execution must be consistent. - If the isolation level is“Serialization”, the read lock will be added when transaction A executes “query value 1”. Transaction B cannot continue execution until transaction A commits. So from A’s point of view,
V1, V2,
Value is 1,V3
The value of theta is 2.
MVCC
Concurrency Control is a Concurrency Control for multi-version Concurrency Control. Read/write conflicts are resolved without locking by reading the history of the specified version and by means of ensuring that the values read match the isolation level at the transaction. 🔗
For the use ofInnoDB
For tables in the storage engine, the clustered index record contains the following two necessary hidden columns:
trx_id
Each time a transaction makes a change to a clustered index record, the transaction’sTransaction id
Assigned totrx_id
Hide the column.
roll_pointer
: Every time a change is made to a clustered index record, the old version is writtenThe undo log
In the. The hidden column acts as a pointer to the record before it was modified.
To determine which version in the version chain is visible to the current transaction, MySQL has devised the concept of ReadView. Four important things are as follows:
m_ids
: Was in the current system when the ReadView was generatedList of active transaction idsmin_trx_id
: Was in the current system when the ReadView was generatedMinimum transaction ID active, which is the minimum value in m_IDSmax_trx_id
: When generating ReadView, the system shouldThe transaction ID value assigned to the next transactioncreator_trx_id
:The transaction ID of the transaction that generated the ReadView
A unique transaction ID is assigned to an insert, delete, or update statement that changes a table record, otherwise the default transaction ID is 0. Max_trx_id is not the maximum value in M_IDS; transaction ids are incrementally assigned. When a new transaction is generated, the value of m_ids will be 1 and 2, min_trx_id will be 1, and max_trx_id will be 4.
The execution process is as follows:
- If the version is accessed
trx_id = creator_id
, meaning that the current transaction is accessing its own modified record, so that version can be accessed by the current transaction; - If the version is accessed
trx_id < min_trx_id
, indicating that the transaction that generated this version was generated in the current transactionReadView
Previously committed, so the version can be accessed by the current transaction; - Of the version being accessed
trx_id >= max_trx_id
, indicating that the transaction that generated this version was generated in the current transactionReadView
This version cannot be accessed by the current transaction. - Of the version being accessed
trx_id
Whether inm_ids
In the list- Is to create
ReadView
, the version is still active and cannot be accessed. Follow the version chain to find the next version of the data, continue to perform the above steps to determine the visibility, if the last version is not visible, it means that the record is completely invisible to the current transaction; - No, create
ReadView
When the transaction that generated the version has been committed and the version can be accessed.
- Is to create
MVCC implements read commit
MVCC implements Read Committed, generating a ReadView before each Read.
Create data table:
CREATE TABLE `girl` (
`id` int(11) NOT NULL.`name` varchar(255),
`age` int(11),
PRIMARY KEY (`id`))ENGINE=InnoDB DEFAULT CHARSET=utf8;
Copy the code
Here are three transactions executed, one line representing a point in time:
Select statement execution process when point in time is 5:
- There are two transactions in the system
id
Transactions of 100,200 are executing. - Generate a ReadView when performing select,
Mids = [100200]
.min_trx_id = 100
.max_trx_id = 201
.creator_trx_id = 0
(The SELECT transaction does not perform the change operation and the transaction ID defaults to 0). - Latest version
name
Listed as Xi Shi, this editiontrx_id
The value is 100 atmids
List, does not meet the visibility requirements, according toroll_pointer
Skip to the next version. - The next version
name
Liwang Zhaojun, the versiontrx_id
The value of 100 is also inmids
List, therefore does not meet the requirements, continue to skip to the next version. - The next version
name
Listed as diao Chan, the versiontrx_id
The value is 10, less thanmin_trx_id
, so the final returnname
The value is diao cicada.
Select statement execution process when point in time is 8:
- There is a transaction in the system
id
A transaction of 200 is executing (transactionid
Transactions for 100 have been committed). - Generate a ReadView when executing the SELECT statement,
mids = [200]
.min_trx_id = 200
.max_trx_id = 201
.creator_trx_id = 0
. - Latest version
name
Listed as Yang Yuhuan, that editiontrx_id
The value is 200mids
List, does not meet the visibility requirements, according toroll_pointer
Skip to the next version. - The next version
name
Listed as Xi Shi, the versiontrx_id
The value is 100, less thanmin_trx_id
, so the final returnname
The value is xi Shi. - When a transaction
id
For 200 transactions committed when the query is obtainedname
Listed as Yang Yuhuan.