This article is published by the official account [Developing Pigeon]! Welcome to follow! ! !
Old Rules-Sister Town House:
One. undo log
(I. Overview
When a transaction is suddenly aborted during execution, in order to ensure the atomicity of the transaction, it needs to be rolled back to its original state. Whenever a record is to be changed, some information needs to be recorded. What is recorded for rollback is called undo Log, that is, undo log.
(Two) transaction id
1. Assign transaction id
If a transaction performs additions, deletions, and modifications to a table during execution, InnoDB will assign a unique transaction id to it. For a read-only transaction, the transaction id will only be assigned when it performs an addition, deletion, and modification operation on a temporary table created by a user for the first time; for a read-write transaction, only when it performs addition, deletion, and modification on a table for the first time When the transaction id is allocated. Sometimes, although we have opened a read-write transaction, but the transaction is full of query statements, it will not be assigned a transaction id.
2. Generation of transaction id
The server maintains a global variable in memory as the transaction id. As long as one is allocated, it will increase by 1. Whenever the value of this variable is a multiple of 256, the value will be refreshed to one of the pages with page number 5 in the system space table. In the attribute named Max_Trx ID. There is a trx_id hidden column in the row format of the InnoDB clustered index record, which records the transaction id of the statement that changes the clustered index record.
(3) Format of the undo log
Generally, every time a record is changed, it corresponds to an undo log, but in some updates, there are also two undo logs. A transaction will generate many undo logs during the execution process. The number starts from 0 and is recorded as undo_no.
1. The undo log corresponding to the INSERT operation
Insert operation, the final result is to put this record in an index page, if you want to roll back this operation, delete this record, that is, when writing the undo log, just write down the primary key information of this record. Yes, no matter how many columns the primary key contains, record the storage space size and true value of each related column. Although inserting a record means inserting a record into both the clustered index and the secondary index, writing the undo log is only for the clustered index, because the record in the secondary index can be found based on the primary key.
There is also a hidden column roll_pointer in the clustered index record, which is a pointer to the undo log corresponding to the record.
2. The undo log corresponding to the DELETE operation
We know that the records inserted into the page will form a singly linked list based on the next_record attribute in the record header information, which is called a normal record linked list; the deleted records will also form a garbage linked list based on next_record, and the storage space in the linked list can be Be reused. There is a PAGE_FREE attribute in Page Header, which points to the head node of the garbage list.
When using the DELETE operation to delete a record, the last record in the normal record linked list is deleted. This deletion process is divided into two steps:
(1) Set the delted_flag flag of the record to 1. This stage is called delete mark. At this time, the record is neither in the normal record linked list nor in the garbage linked list, and is in an intermediate stage.
(2) When the transaction in which the delete statement is located is committed, a special thread will add the record to the garbage list. This stage is called purge. After that, this record is considered to have been deleted, and the storage space occupied can be reused. Note that the first insertion method is used to add to the garbage list.
Since the transaction is committed, we do not need to roll back the transaction. For the rollback of the DELETE operation, we only need to consider rolling back the delete mark process. Before performing the delete mark operation on a record, the old values of trx_id and roll_pointer of the record need to be recorded in the trx_id and roll_pointer of the corresponding undo log, so that we can find the last time the record was modified through this undo log Undo log. The undo linked list formed by the concatenation of roll_pointer pointers is called the version chain.
3. The undo log corresponding to the UPDATE operation
When performing an UPDATE operation, InnoDB has two treatments for updating the primary key and not updating the primary key.
(1) Do not update the primary key
It can be further subdivided into the unchanged and changing storage space occupied by the updated column. If the updated column does not change, you can update it in place, that is, modify the value of the corresponding column directly on the basis of the original record; if the space of the updated column changes, you need to delete the record from the clustered index first, and then create it based on the new value A new record is inserted into the page. The delete operation here is to directly add the garbage list to modify the statistical information. If the storage space occupied by the newly created record does not exceed the space of the old record, the old space can be reused directly.
(2) Update the primary key
For the operation of updating the primary key, it means that the position of this record in the clustered index will change. First, delete the old record. The reason for only the delete mark operation is that other transactions may also access this at the same time. Record, if you directly delete other transactions added to the garbage list, you will not be able to access it. Create a new record based on the updated value and insert it into the clustered index page. In this case, two undo logs will be generated, one for delete mark operation and one for insert operation.
(4) General linked list structure
In the process of writing the undo log, multiple linked lists are used, and many linked lists have the same structure. In a certain table space, we can locate a node's position by the page number of a page and the offset within the page. Linked list nodes usually include the page numbers and offsets that point to the front and back nodes, occupying 12 bytes; the base node of the linked list includes the head node, the end node and the length of the linked list, which is 16 bytes.
(5) Undo log type
There are basically two types, one is the undo log generated by the INSERT statement or the statement that updates the primary key in the UPDATE statement, called insert undo log; the other is generated by the DELETE, UPDATE statement, called update undo log. One page can only store one type of undo log, and different types of undo logs cannot be mixed together.
(6) Undo page linked list
A transaction contains many statements. One record may modify multiple records. Each modification needs to record 1-2 undo logs. These logs may not fit on one page and need to be placed on multiple pages. This requires These undo pages are connected into different linked lists. During the execution of a transaction, there will be multiple types of statements, which will generate different types of undo logs, which can only be placed in different pages. Therefore, in the execution of a transaction, two linked lists of undo pages are required, one is Insert undo linked list, one is update undo linked list. At the same time, InnoDB should distinguish between the undo logs of ordinary tables and temporary tables, so a transaction has up to 4 linked lists with undo logs as nodes. These linked lists are allocated on demand and will only be created when needed.