Main quotes from the article notes:
transaction characteristics
Atomicity: Either all is completed or none is completed , which is guaranteed by undo log ( rollback log );
Consistency: The database maintains a consistent state before and after transaction operations . It is guaranteed through persistence + atomicity + isolation;
Isolation: Preventing data inconsistency due to cross-execution when multiple transactions are executed concurrently is guaranteed through MVCC ( Multiple Version Concurrency Control ) or lock mechanism;
Durability: Data modifications are permanent and are guaranteed by redo log;
How does the database ensure atomicity?
Mainly using Innodb's undo log . When a transaction is rolled back, all successfully executed SQL statements can be revoked. It needs to record the corresponding log information you want to roll back. For example
- When you delete a piece of data, you need to record the information of the data. When rolling back, insert the old data.
- When you update a piece of data, you need to record the old value. When rolling back, perform the update operation based on the old value.
- When inserting a piece of data, the primary key of this record is needed. When rolling back, the delete operation is performed based on the primary key.
The undo log records the information required for rollback. When the transaction execution fails or rollback is called, causing the transaction to be rolled back, the information in the undo log can be used to roll back the data to the way it was before modification.
How does the database ensure durability?
When data is modified, not only the operation is performed in memory, but the operation is also recorded in the redo log . When the transaction is committed, the redo log will be flushed ( part of the redo log is in memory and part is on disk). When the database is down and restarted, the contents in the redo log will be restored to the database, and then the data will be rolled back or submitted based on the contents of the undo log and binlog .
What are the benefits of using redo log?
In fact, the advantage is that flushing the redo log is more efficient than flushing the data page. The specific performance is as follows:
- The redo log is small in size. After all, it only records which page has been modified. Therefore, the redo log is small in size and can be refreshed quickly.
- The redo log is appended to the end and belongs to sequential IO. The efficiency is obviously faster than random IO.
Problems with parallel transactions
-
Dirty read: Read uncommitted data from other transactions ;
-
Non-repeatable reading: The data read before and after is inconsistent ;
-
Phantom reading: The number of records read before and after is inconsistent .
What is the difference between non-repeatable read and phantom read? Can you give an example?
The focus of non-repeatable reading is modification, and the focus of phantom reading is addition or deletion.
Database isolation level
-
Read uncommitted means that before a transaction is committed, the changes it makes can be seen by other transactions; dirty reads, non-repeatable reads, and phantom reads may occur;
-
Read committed means that only after a transaction is committed, the changes it makes can be seen by other transactions; non-repeatable reads and phantom reads may occur, but dirty reads are impossible;
-
Repeatable read refers to the data seen during the execution of a transaction, which is always consistent with the data seen when the transaction is started. The default isolation level of the MySQL InnoDB engine ; phantom reading may occur, but it is impossible Dirty read and non-repeatable read phenomena;
-
Serializable (serializable) ; a read-write lock will be added to the record. When multiple transactions read and write this record, if a read-write conflict occurs, the transaction accessed later must wait for the completion of the previous transaction. , to continue execution; dirty reads, non-repeatable reads and phantom reads are unlikely to occur.
How are these four isolation levels implemented?
-
For transactions with the "read uncommitted" isolation level, because the data modified by the uncommitted transaction can be read, it is enough to read the latest data directly;
-
For transactions at the "serialized" isolation level, parallel access is avoided by adding read-write locks ;
-
For transactions with "Read Commit" and "Repeatable Read" isolation levels, they are implemented through Read View. The difference lies in the timing of creating Read View. You can understand Read View as a data snapshot. Just like a camera taking pictures, it freezes the scenery at a certain moment. The "Read Commit" isolation level regenerates a Read View "before each statement is executed", while the "Repeatable Read" isolation level generates a Read View "when starting a transaction", and then uses this Read during the entire transaction. View .
Although the default isolation level of the MySQL InnoDB engine is "repeatable read", it largely avoids the phantom read phenomenon (it does not completely solve it) . There are two solutions:
-
For snapshot reads (ordinary select statements), phantom reads are solved through MVCC , because under the repeatable read isolation level, after starting the transaction (after executing the begin statement), after executing the first query statement, a Read View will be created , the data seen during the execution of the transaction is always consistent with the data seen when the transaction is started . Even if another transaction inserts a piece of data in the middle, the data cannot be queried, so it is very good to avoid phantoms. Read the question.
-
For the current read (select ... for update and other statements), the phantom read is solved by next-key lock (record lock + gap lock) , because when the select ... for update statement is executed, next will be added -key lock, if another transaction inserts a record within the next-key lock lock range, then the insert statement will be blocked and cannot be successfully inserted, so it is very good to avoid phantom reading problems.
I gave two examples of scenarios where phantom reading occurs.
First example: For snapshot reads, MVCC cannot completely avoid phantom reads. Because when transaction A updates a record inserted by transaction B, the record entries queried twice before and after transaction A are different, so phantom reading occurs.
Second example: For the current read, if the current read is not executed after the transaction is started, but the snapshot read is performed first, and then if other transactions insert a record during this period, then when the transaction subsequently uses the current read for query, it will It was found that the record entries of the two queries were different, so phantom reading occurred.
How does Read View work in MVCC?
Read View has four important fields:
-
m_ids: refers to the transaction ID list of "active transactions" in the current database when creating Read View. Note that it is a list. "Active transactions" refers to transactions that have been started but not yet submitted .
-
min_trx_id: refers to the transaction with the smallest transaction ID among the "active transactions" in the current database when creating the Read View , which is the minimum value of m_ids.
-
max_trx_id: This is not the maximum value of m_ids, but the id value that should be given to the next transaction in the current database when creating the Read View , which is the maximum transaction id value + 1 in the global transaction;
-
creator_trx_id: refers to the transaction ID of the transaction that created the Read View .
Knowing the fields of Read View, we also need to understand the two hidden columns in the clustered index record. :
- trx_id, when a transaction changes a certain clustered index record, the transaction ID of the transaction will be recorded in the trx_id hidden column ;
- roll_pointer, every time a clustered index record is modified, the old version record will be written to the undo log, and then this hidden column is a pointer, pointing to each old version record , so you can use it to find the previous version record of.
The repeatable read isolation level generates a Read View when starting a transaction, and then uses this Read View during the entire transaction .
First check whether the trx_id in the record field is smaller than min_trx_id. If so, then the transaction is visible. Between min_trx_id and max_trx_id, you need to determine whether the trx_id value is within the range of m_ids. If the result is yes, it means that this record was modified by an uncommitted transaction. At this time, the transaction will not read this version. record of. At this time, the transaction will not read this version of the record. Instead, go down the undo log chain to find the old version of the record until you find the first record whose trx_id is "less than" the min_trx_id value in the Read View of the current transaction.
The read-commit isolation level generates a new Read View every time data is read .
Why is there a transaction rollback mechanism in MySQL?
In MySQL, the recovery mechanism is implemented through the rollback log (undo log). All transaction modifications will be recorded in the rollback log first, and then the corresponding rows in the database will be written. Once a transaction has been committed, it cannot be rolled back again.
The functions of the rollback log: 1) It can provide rollback-related information when an error occurs or the user executes ROLLBACK. 2) After the entire system crashes and the database process is directly killed, when the user starts the database process again , it can also immediately pass Querying the rollback log rolls back previously unfinished transactions , which requires the rollback log to be persisted to the disk before the data. This is the main reason why we need to write the log first and then the database.