How to achieve by simply locking RC isolation level of isolation?
Mysql database supports row-level locking in InnoDB engine, increased through access to the transaction exclusive lock (X lock) can prevent access to other affairs, only submission is before commit can access, avoid dirty reads generated in the transaction lock. But in the scene to read, if a transaction during the update operation, followed by many requests simply want to read, but because there is a lock can only wait. This method greatly reduces the efficiency in the multi-read concurrent environment.
Real situation due to the InnoDB uses MVCC mechanism under the RC and RR isolation level, achieve the consistency of non-blocking reads and improve the efficiency of concurrent read and write. In fact, the latest snapshot version is read before the transaction occurs.
MVCC implementation principle (for RC and RR isolation levels are only two kinds of MVCC)
1. version chain
For InnoDB storage engine tables, its clustered index records will include the necessary two hidden column (row_id is not necessary if the table we created has a primary key or unique non-null key will no longer create row_id)
-
6-byte transaction ID (DB_TRX_ID) a record of each event of changes , corresponding to the transaction ID value will assign DB_TRX_ID hidden column (i.e., each row of this field will record the last record set this field to modify transaction id)
-
7 rollback byte pointer (DB_ROLL_PTR) each time a record time improvements , this will keep a pointer hidden column, the recording information before the modification can be found by the pointer
-
Hide ID
2.MVCC implementation dependent:
-
undo log: undo log record multiple versions of data rows of the table, which is the rollback process of transaction execution, in fact, a line MVCC multiple versions of the original data mirroring data.
-
read view: mainly used to determine the visibility of the current version of the data
-
Creating readvew time: at (RC) of the isolation level, each initiate SELECT creates readview; in the RR isolation level, the transaction in the first SELECT request will begin creating readview. It is because of the opportunity to create readview different decision RC isolation level to avoid dirty reads, but can not avoid non-repeatable read.
read view contains four important elements
-
m_ids: system system active in generating readview current list of transaction id read and write transactions [current affairs (New Services) and is being memory commit transaction is not active transactions list]
-
min_trx_id: indicates the current system active in generating read and write transactions readview smallest transaction id, i.e. the minimum m_ids
-
max_trx_id: generating a system readview should be assigned to the next value of a transaction id
-
creator_trx_id: represents the transaction id of the transaction generated readview
Note that : max_trx_id not m_ids maximum value, the transaction id is incremental distribution. For example, now id 1,2,3 these three transactions, the transaction is submitted after id 3. When generating transaction readview, m_ids including 1, wherein the value is min_trx_id 1, the value is 4 max_trx_id
-
3. The current transaction read the specific procedure when a row record (Note: the current transaction and commit transaction being in memory is not readview active list):
In innodb in, after creating a new transaction isolation level in the RC and each time the SELECT statement, the current system will be active innodb list of transactions to create a copy (read view), save a copy of the current system is this transaction should not be id a list of other things to see. A user creates a current affairs, when he wanted to read the lines recorded, innodb this line it will record the current version number and readview compare, comparison process is as follows:
| When have ReadView, every time there is a transaction when you want to access a bar rows, just follow the steps below to determine the current version of the record is visible row |
|---|
| 1. If DB_TRX_ID property value in the row <ReadView in min_trx_id words, indicating the formation of this version of the record of the transaction has already submitted prior to this transaction is created, so the current value of the bank records are visible. Skip to step 5. |
| 2. If DB_TRX_ID property values in the row of> = ReadView in max_trx_id (As mentioned earlier, this maximum is not active transactions list), then generate this version of the show recorded transaction before opening after this transaction readview created, Therefore, the current value is not visible, go to step 4. |
| 3. If the readView min_trx_id <= DB_TRX_ID attribute value <= ReadView in max_trx_id, then a determination is required, if the transaction DB_TRX_ID active list, not visible, returns 4, if the transaction is not in the active list, the description of this version generated the transaction has been submitted, we can read, return 5. |
| 4. Remove the latest version from the undo-log record DB_ROLL_PTR row pointer is in the rollback, it will assign the DB_TRX_ID, then skip to step 1. |
| 5. The value of visible rows returned. |
| 6. If the transaction id is equal access readview in creator_trx_id, meaning that the current visit in its own affairs |
4. The process of updating rows
-
The initial data lines. F1 ~ F6 is the name of the field, should the value of 1 to 6 for the field. Fields are hidden behind the three and the number of transaction to be rolled back row pointer, if this is just insert the data can be considered as the ID 1, the other two fields are empty.
-
Session1 change the value of each field of the line, the operation will be made to the following figure:
With exclusive lock (X lock) lock diverted
Redo log record
Copy the value before the modification diverted to undo log
Modifying the current value of a row, a transaction number for the current 01 (for example 01 to fill) the pointer to the row before the rollback undo log modified
-
Session2 again modify the value of the row, step Session1 is substantially the same, but this time there are two rows undo log record, and a pointer connected together by a rollback
MVCC multi-version concurrency control 5.InnoDB
MVCC makes use when reading data, Innodb almost can not obtain any locks, each query by checking the version, the version received only data they need, thus greatly improving the concurrency of the system. But the disadvantage of this strategy is that each row of records need extra storage space, more inspections and an extra maintenance work.
But Innodb not simply use MVCC, but instead of using MVCC read lock on a read, performing other operations still need to use an exclusive lock.
When the transaction only modify a row when using MVCC is possible, but when the modification involves multi-line records, MVCC it insufficient. For example, a transaction executed ideal MVCC, you want to modify two rows of data, the first line of the amendment is successful, but the second line modification operation fails and needs to roll back the first line, but that line did not add the first row locks, the transaction may b this time on the second line has been modified, but if a transaction has been rolled back later, it carried out operations in the transaction will be destroyed b
So Innodb just borrowed the name MVCC provides non-blocking reads. Still used when writing data exclusive lock (lock not use space, it can still perform inserts, so you can not avoid phantom read), other transactions can still read the data locked because reading it just mirrored version