Shulou(Shulou.com)05/31 Report--

What is the principle of InnoDB data page in MySQL? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Introduction to different types of pages

It is the basic unit for InnoDB to manage storage space, and the size of a page is generally 16KB. InnoDB designs many different types of pages for different purposes, such as pages that store tablespace header information, pages that store Insert Buffer information, pages that store INODE information, pages that store undo log information and so on. Of course, if you haven't heard of any of these nouns, let's just say I farted. But it doesn't matter. We're not going to talk about these types of pages today. We focus on those pages that store the records in our tables. Officially, we call these pages INDEX pages, since we don't know what an index is. And the records in these tables are what we call data in daily life, so at present, we still call this kind of page that stores records as data pages.

Quick browsing of data page structure

The 16KB-sized storage space represented by the data page can be divided into multiple parts, and different parts have different functions, as shown in the figure:

As can be seen from the figure, the storage space of an InnoDB data page is roughly divided into seven parts, some of which occupy a certain number of bytes and some of which occupy an uncertain number of bytes. Let's use a table to roughly describe what is stored in these seven parts (just take a quick glance, which will be nagged later):

The size of the space occupied by the name in the name briefly describes some general information in the File Header file header 38 byte pages some general information in the Page Header page header 56 bytes data page specific information Infimum + Supremum minimum record and maximum record 26 bytes two virtual row records User Records user records uncertain actual stored row records content Free Space free space uncertain pages unused Page Directory page directory uncertainty Relative position of some records in the page the trailing 8-byte check page of the File Trailer file is complete.

Storage recorded in the page

Of the seven components of the page, our own stored records are stored in the User Records section in the row format we specified. But at the beginning of the page generation, there is no User Records part. Every time we insert a record, we will apply for a record size space from the Free Space part, that is, the unused storage space, to divide the record size into the User Records part. When the space in the Free Space part is completely replaced by the User Records part, it means that the page is used up, if there are new records inserted. You need to apply for a new page. The diagram of the process is as follows:

InnoDB took a lot of effort to better manage these records in User Records. Where? Don't you just put the records in the User Records section according to the specified row format? In fact, this has to start with the record header information in the record line format.

The secret of recording header information

For the smooth development of the story, let's first create a table:

Mysql > CREATE TABLE page_demo (- > C1 INT,-> c2 INT,-> c3 VARCHAR (10000),-> PRIMARY KEY (C1)->) CHARSET=ascii ROW_FORMAT=Compact;Query OK, 0 rows affected (0.03 sec)

The newly created page_demo table has three columns, of which columns C1 and c2 are used to store integers, and column c3 is used to store strings. It is important to note that we specify the C1 column as the primary key, so there is no need for InnoDB to create the so-called row_id hidden column for us in the specific row format. And we specify the ascii character set and the row format of Compact for this table. So the row format diagram recorded in this table looks like this:

As you can see from the figure, we have deliberately marked out the 5 bytes of the record header information, indicating that it is very important. Once again, let's take a look at the general meaning of the attributes in these record header information (we are currently using the Compact line format for demonstration):

The name size (in bit) describes that the reservation bit 11 does not use the reservation bit 21 and does not use delete_mask1 to mark whether the record is deleted or not. The minimum record in each layer of the min_rec_mask1B+ tree non-leaf node adds the tag n_owned4 indicates the number of records owned by the current record heap_no13 represents the location information of the current record in the record heap record_type3 indicates the type of current record, and 0 indicates the type of current record. 1 represents the non-leaf node record of the B+ tree, 2 represents the minimum record, and 3 indicates the maximum record next_record16 represents the relative position of the next record

Since we are mainly talking about the role of recording header information, for the convenience of understanding, we only draw the relevant header information attributes and the information of C1, c2 and c3 columns in the row format demonstration diagram of the page_ demo. just because other information is not drawn does not mean they do not exist, it is just omitted in the diagram for the convenience of understanding. This is the simplified row format diagram:

Let's try to insert a few records into the page_ demotion table:

Mysql > INSERT INTO page_demo VALUES (1,100, 'aaaa'), (2,200,' bbbb'), (3,300, 'cccc'), (4,400,' dddd'); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0

To make it easier for you to analyze how these records are represented in the User Records section of the page, I represent the header information in the record and the actual column data in decimal (actually a bunch of binary bits), so the schematic diagram of these records is:

When looking at this picture, it should be noted that there is no gap when each record is stored in User Records. Here, each record is drawn on a separate line just for the convenience of viewing. Let's take a look at the meaning of the attributes in the record header information against this diagram:

Delete_mask

This attribute marks whether the current record has been deleted, occupying a binary bit. A value of 0 means that the record has not been deleted, and a value of 1 means that the record has been deleted.

What? Is the deleted record still on the page? Yes, what is done on the table may be quite different from what you do behind the back. you think it has been deleted, but it is still on the real disk. The reason why these deleted records are not immediately removed from disk is that rearranging other records on disk after removing them requires performance consumption, so it is just a delete mark. All deleted records form a so-called junk linked list, and the space occupied by the records in this linked list is called the so-called reusable space, and then if new records are inserted into the table. It is possible to overwrite the storage space occupied by these deleted records.

Min_rec_mask

This tag is added to the minimum record in each layer of the non-leaf node of the B+ tree. What is a B+ tree? What is a non-leaf node? All right, we'll talk about this later. Anyway, the min_rec_ Mak values of the four records we inserted ourselves are all 0, which means that none of them are the smallest records among the non-leaf nodes of the B + tree.

N_owned

This is kept secret for the time being. It will be the protagonist later.

Heap_no

This property indicates the location of the current record on this page. As you can see from the figure, the positions of the four records we inserted on this page are: 2, 3, 4, 5. Is there something missing? Yes, why are there no records with heap_ no values of 0 and 1?

This is actually a little trick played by the uncles who designed InnoDB. They automatically add two records to each page. Because these two records are not inserted by ourselves, they are sometimes called pseudo records or virtual records. One of these two pseudo records represents the minimum record and the other represents the maximum record. Wait a minute, can the record be compared to the size?

Yes, records can also be compared to size, and for a complete record, comparing the size of the record is comparing the size of the primary key. For example, the primary key values of the four rows of records we insert are: 1, 2, 3, 4, respectively, which means that the size of these four records increases in turn from small to large.

But no matter how many records we insert into the page, the uncles who designed the InnoDB stipulated that the two pseudo records they defined were the minimum record and the maximum record. The construction of these two records is very simple, consisting of 5-byte header information and a fixed part of 8-byte size, as shown in the figure.

Since these two records are not our own defined records, they are not stored in the User Records section of the page, but are placed separately in a section called Infimum + Supremum, as shown in the figure:

We can see from the figure that the heap_ no values of the minimum record and the maximum record are 0 and 1, respectively, which means that they are at the top.

Record_type

This attribute represents the type of current record, and there are four types of records, 0 for normal records, 1 for B+ tree non-leaf node records, 2 for minimum records, and 3 for maximum records. We can also see from the figure that the records we insert are ordinary records with record_ type values of 0, while the minimum and maximum records have record_ type values of 2 and 3, respectively.

As for the case where record_type is 1, we will emphasize it later when we talk about the index.

Next_record

This is very important because it represents the address offset from the real data currently recorded to the next recorded real data. For example, the next_ record value of the first record is 32, which means that 32 bytes from the address of the real data of the first record is the real data of the next record. If you are familiar with the data structure, you will immediately understand that this is actually a linked list, and you can find its next record through one record. It is important to note, however, that the next record does not refer to the next record in the order in which we insert it, but to the next record in the order in which the primary key values go from small to large. Moreover, the next record that specifies the Infimum record (that is, the minimum record) is the user record with the lowest primary key value on this page, while the next record of the user record with the largest primary key value on this page is the Supremum record (that is, the maximum record). In order to more vividly express the role of this next_record, we use arrows to replace the address offset in next_record:

As you can see from the figure, our records form a single linked list in the order of the primary key from small to large. The next_record value of the maximum record is 0, which means that the maximum record has no next record, which is the last node in the single linked list. If you delete a record from it, the linked list will also change, for example, if we delete the second record:

Mysql > DELETE FROM page_demo WHERE C1 = 2 * query OK, 1 row affected (0.02 sec)

The schematic diagram after deleting the second record is:

As you can see from the figure, these changes mainly took place before and after the deletion of the second record:

Therefore, no matter how we add, delete or modify the records in the page, InnoDB will always maintain a single linked list of records, and the nodes in the linked list are connected in the order of primary key values.

The second record is not removed from the storage space, but the delete_ mask value of the record is set to 1.

The next_ record value of the second record becomes 0, which means that there is no next record for the record.

The next_record of the first record points to the third record.

Another thing you may have overlooked is that the nowned value of the maximum record has changed from 5 to 4, which we will explain in detail later.

Let's take a look at another interesting thing, because we deleted the record with a primary key value of 2, but the storage space was not reclaimed. What happens if we insert this record into the table again?

Mysql > INSERT INTO page_demo VALUES (2,200, 'bbbb'); Query OK, 1 row affected (0.00 sec)

Let's take a look at the storage of records:

As you can see from the figure, InnoDB does not request new storage space for it because of the insertion of new records, but directly reuses the storage space of the original deleted records.

Page Directory (page directory)

Now that we know that records are concatenated into a single linked list in the order of primary key values on the page, what if we want to find a record in the page based on the primary key values? For example, a query statement like this:

SELECT * FROM page_demo WHERE C1 = 3

The stupidest way: start with the Infimum record (minimum record), look all the way back along the linked list, and one day you will find it (or you can't find it), and you can be opportunistic when looking for it, because the values of each record in the linked list are arranged from small to large, so when a node in the linked list represents a record whose primary key value is greater than the primary key value you are looking for, you can stop searching. Because the primary key value of the node behind the node increases in turn.

This method can be used when the number of records stored in the page is relatively small. For example, now we have only 4 records inserted by ourselves in our table, so we can traverse all the records by looking for them at most 4 times. But if a page stores a lot of records, this search is still a loss of performance, so we say this kind of traversal search is a stupid way. But who are the uncles who designed InnoDB, and can they use such a stupid way, of course, to design a more 6 way to find it? they found inspiration in the catalogue of books.

When we usually want to find something from a book, we usually look at the catalog first, find the page number of the book corresponding to the content we need to find, and then go to the corresponding page number to check the content. The uncles who designed InnoDB made a similar catalog for our records, and their production process goes like this:

Divide all normal records, including maximum and minimum records, excluding those marked as deleted, into groups.

The n_owned attribute in the header information of the last record in each group (that is, the largest record in the group) indicates how many records the record has, that is, how many records are in the group.

The address offset of the last record of each group is extracted separately and stored sequentially near the end of the page, which is called Page Directory, the page directory (you should look back at the diagram of the various parts of the page at this point). These address offsets in the page directory are called slots (English name: Slot), so this page directory is made up of slots.

For example, there are six normal records in the page_demo table. InnoDB will divide them into two groups. There is only one minimum record in the first group, and the remaining five records in the second group. See the diagram below:

From this picture, we need to pay attention to the following points:

Now there are two slots in the page directory section, which means that our record is divided into two groups, and the value in slot 1 is 112, which represents the maximum recorded address offset (that is, 112 bytes from 0 bytes on the page). The value in slot 0 is 99, which represents the minimum recorded address offset.

Note the n_owned attribute in the header information of the minimum and maximum records

The nowned value of the minimum record is 1, which means that there is only one record in the group ending with the minimum record, that is, the minimum record itself.

The nowned value of the maximum record is 5, which means that there are only five records in the group ending with the maximum record, including the maximum record itself and the four records we inserted ourselves.

Address offsets such as 99 and 112 are not intuitive, and we use arrows instead of numbers, which makes it easier for us to understand, so the modified diagram looks like this:

Alas, it looks strange. Such a messy picture is really unbearable for my obsessive-compulsive disorder, so let's just take a logical look at the relationship between these records and the page directory, regardless of the arrangement of each record on the storage device for the time being:

It's much more pleasing to the eye! Why is it that the minimum record has a n _ owned value of 1 and the maximum record has a nowned value of 5? is there anything wrong with this?

Yes, the uncles who designed the InnoDB have a rule on the number of records in each group: there can only be one record for the minimum record group, only 1 record for the maximum group, and 4 records for the rest of the grouping. So the grouping is done according to the following steps:

In the initial case, there are only two records in a data page, the minimum record and the maximum record, and they belong to two groups.

After that, every time a record is inserted, the slot in which the primary key value is larger than the primary key value of this record and the smallest difference is found from the page directory, and then the n_owned value of the record corresponding to this slot is added by 1, indicating that another record has been added to the group until the number of records in the group is equal to 8.

When one record is inserted after the number of records in a group is equal to eight, the records in the group are split into two groups, four records in one group and five records in the other. This process adds a slot to the page directory to record the offset of the largest record in the new group.

Because there are too few records in the page_ demotion table to demonstrate the process of speeding up the lookup after adding a page directory, add some more records to the page_demo table:

Mysql > INSERT INTO page_demo VALUES (5,500, 'eeee'), (6,600,' ffff'), (7,700, 'gggg'), (8,800,' hhhh'), (9,900, 'iiii'), (10, 1000,' jjjj'), (11, 1100, 'kkkk'), (12, 1200,' llll'), (13, 1300, 'mmmm'), (14, 1400,' nnnn'), (15, 1500) 'oooo'), (16, 1600,' pppp') Query OK, 12 rows affected (0.00 sec) Records: 12 Duplicates: 0 Warnings: 0

Ha, we added 12 more records to the table in one breath, and now there are 18 records (including the minimum and maximum records) on the page, which are divided into five groups, as shown in the figure:

Because drawing all the information of the 16 records in one picture takes up too much space, it is dazzling, so only the n_owned and next_record attributes in the user record header information are retained, and the arrows between the records are omitted. Now let's see how to find records from this page catalog. Because the primary key values of the records represented by each slot are sorted from small to large, we can use the so-called dichotomy to find them quickly. The numbers of the five slots are 0,1,2,3,4 respectively, so the lowest slot in the initial case is low=0, and the highest slot is high=4. For example, if we want to find a record with a primary key value of 6, the process goes like this:

The position of the middle slot is calculated: (0,4) / 2, so the primary key value recorded by slot 2 is 8, and because 8 > 6, the setting high=2,low remains the same.

Recalculate the position of the middle slot: (0,2) / 2: 1, so check that the primary key value for slot 1 is 4, and because 4

< 6，所以设置low=1，high保持不变。 因为high - low的值为1，所以确定主键值为6的记录在槽2对应的组中。此刻我们需要找到槽2中主键值最小的那条记录，然后沿着单向链表遍历槽2中的记录。但是我们前边又说过，每个槽对应的记录都是该组中主键值最大的记录，这里槽2对应的记录是主键值为8的记录，怎么定位一个组中最小的记录呢？别忘了各个槽都是挨着的，我们可以很轻易的拿到槽1对应的记录（主键值为4），该条记录的下一条记录就是槽2中主键值最小的记录，该记录的主键值为5。所以我们可以从这条主键值为5的记录出发，遍历槽2中的各条记录，直到找到主键值为6的那条记录即可。由于一个组中包含的记录条数只能是1~8条，所以遍历一个组中的记录的代价是很小的。 所以在一个数据页中查找指定主键值的记录的过程分为两步： 通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录。 通过记录的next_record属性遍历该槽所在的组中的各个记录。 Page Header（页面头部） 设计InnoDB的大叔们为了能得到一个数据页中存储的记录的状态信息，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等，特意在页中定义了一个叫Page Header的部分，它是页结构的第二部分，这个部分占用固定的56个字节，专门存储各种状态信息，具体各个字节都是干嘛的看下表： 名称占用空间大小描述PAGE_N_DIR_SLOTS2字节在页目录中的槽数量PAGE_HEAP_TOP2字节还未使用的空间最小地址，也就是说从该地址之后就是Free SpacePAGE_N_HEAP2字节本页中的记录的数量（包括最小和最大记录以及标记为删除的记录）PAGE_FREE2字节第一个已经标记为删除的记录地址（各个已删除的记录通过next_record也会组成一个单链表，这个单链表中的记录可以被重新利用）PAGE_GARBAGE2字节已删除记录占用的字节数PAGE_LAST_INSERT2字节最后插入记录的位置PAGE_DIRECTION2字节记录插入的方向PAGE_N_DIRECTION2字节一个方向连续插入的记录数量PAGE_N_RECS2字节该页中记录的数量（不包括最小和最大记录以及被标记为删除的记录）PAGE_MAX_TRX_ID8字节修改当前页的最大事务ID，该值仅在二级索引中定义PAGE_LEVEL2字节当前页在B+树中所处的层级PAGE_INDEX_ID8字节索引ID，表示当前页属于哪个索引PAGE_BTR_SEG_LEAF10字节B+树叶子段的头部信息，仅在B+树的Root页定义PAGE_BTR_SEG_TOP10字节B+树非叶子段的头部信息，仅在B+树的Root页定义 如果大家认真看过前边的文章，从PAGE_N_DIR_SLOTS到PAGE_LAST_INSERT以及PAGE_N_RECS的意思大家一定是清楚的，如果不清楚，对不起，你应该回头再看一遍前边的文章。剩下的状态信息看不明白不要着急，饭要一口一口吃，东西要一点一点学（一定要稍安勿躁哦，不要被这些名词吓到）。在这里我们先唠叨一下PAGE_DIRECTION和PAGE_N_DIRECTION的意思： PAGE_DIRECTION 假如新插入的一条记录的主键值比上一条记录的主键值大，我们说这条记录的插入方向是右边，反之则是左边。用来表示最后一条记录插入方向的状态就是PAGE_DIRECTION。 PAGE_N_DIRECTION 假设连续几次插入新记录的方向都是一致的，InnoDB会把沿着同一个方向插入记录的条数记下来，这个条数就用PAGE_N_DIRECTION这个状态表示。当然，如果最后一条记录的插入方向改变了的话，这个状态的值会被清零重新统计。 至于我们没提到的那些属性，我没说是因为现在不需要大家知道。不要着急，当我们学完了后边的内容，你再回头看，一切都是那么清晰。 File Header（文件头部） 上边唠叨的Page Header是专门针对数据页记录的各种状态信息，比方说页里头有多少个记录了呀，有多少个槽了呀。我们现在描述的File Header针对各种类型的页都通用，也就是说不同类型的页都会以File Header作为第一个组成部分，它描述了一些针对各种页都通用的一些信息，比方说这个页的编号是多少，它的上一个页、下一个页是谁啦吧啦吧啦～ 这个部分占用固定的38个字节，是由下边这些内容组成的： 名称占用空间大小描述FIL_PAGE_SPACE_OR_CHKSUM4字节页的校验和（checksum值）FIL_PAGE_OFFSET4字节页号FIL_PAGE_PREV4字节上一个页的页号FIL_PAGE_NEXT4字节下一个页的页号FIL_PAGE_LSN8字节页面被最后修改时对应的日志序列位置（英文名是：Log Sequence Number）FIL_PAGE_TYPE2字节该页的类型FIL_PAGE_FILE_FLUSH_LSN8字节仅在系统表空间的一个页中定义，代表文件至少被刷新到了对应的LSN值FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID4字节页属于哪个表空间 对照着这个表格，我们看几个目前比较重要的部分： FIL_PAGE_SPACE_OR_CHKSUM 这个代表当前页面的校验和（checksum）。啥是个校验和？就是对于一个很长很长的字节串来说，我们会通过某种算法来计算一个比较短的值来代表这个很长的字节串，这个比较短的值就称为校验和。这样在比较两个很长的字节串之前先比较这两个长字节串的校验和，如果校验和都不一样两个长字节串肯定是不同的，所以省去了直接比较两个比较长的字节串的时间损耗。 FIL_PAGE_OFFSET 每一个页都有一个单独的页号，就跟你的身份证号码一样，InnoDB通过页号来可以唯一定位一个页。 FIL_PAGE_TYPE 这个代表当前页的类型，我们前边说过，InnoDB为了不同的目的而把页分为不同的类型，我们上边介绍的其实都是存储记录的数据页，其实还有很多别的类型的页，具体如下表： 类型名称十六进制描述FIL_PAGE_TYPE_ALLOCATED0x0000最新分配，还没使用FIL_PAGE_UNDO_LOG0x0002Undo日志页FIL_PAGE_INODE0x0003段信息节点FIL_PAGE_IBUF_FREE_LIST0x0004Insert Buffer空闲列表FIL_PAGE_IBUF_BITMAP0x0005Insert Buffer位图FIL_PAGE_TYPE_SYS0x0006系统页FIL_PAGE_TYPE_TRX_SYS0x0007事务系统数据FIL_PAGE_TYPE_FSP_HDR0x0008表空间头部信息FIL_PAGE_TYPE_XDES0x0009扩展描述页FIL_PAGE_TYPE_BLOB0x000A溢出页FIL_PAGE_INDEX0x45BF索引页，也就是我们所说的数据页 我们存放记录的数据页的类型其实是FIL_PAGE_INDEX，也就是所谓的索引页。至于啥是个索引，且听下回分解～ FIL_PAGE_PREV和FIL_PAGE_NEXT 我们前边强调过，InnoDB都是以页为单位存放数据的，有时候我们存放某种类型的数据占用的空间非常大（比方说一张表中可以有成千上万条记录），InnoDB可能不可以一次性为这么多数据分配一个非常大的存储空间，如果分散到多个不连续的页中存储的话需要把这些页关联起来，FIL_PAGE_PREV和FIL_PAGE_NEXT就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了，而无需这些页在物理上真正连着。需要注意的是，并不是所有类型的页都有上一个和下一个页的属性，不过我们本集中唠叨的数据页（也就是类型为FIL_PAGE_INDEX的页）是有这两个属性的，所以所有的数据页其实是一个双链表，就像这样：

We can't use the other attributes of File Header for the time being. We'll talk about it when we need it.

File Trailer

We know that the InnoDB storage engine will store data on disk, but the disk is too slow and needs to be loaded into memory for processing on a page-by-page basis. If the data in the page is modified in memory, then the data needs to be synchronized to disk at some time after modification. But what if the power is cut off in the middle of synchronization? isn't that inexplicably awkward? In order to check whether a page is complete (that is, whether the embarrassment of only half synchronization occurs during synchronization), the uncles who designed InnoDB added a File Trailer section at the end of each page, which consists of 8 bytes and can be divided into two small parts:

The first four bytes represent the checksum of the page

This section corresponds to the checksum in File Header. Every time a page is modified in memory, its checksum should be calculated before synchronization, because the File Header is in the front of the page, so the checksum will be synchronized to the disk first, and when fully written, the checksum will also be written to the end of the page, if the full synchronization is successful, the checksum of the head and tail of the page should be the same. If the power is off halfway through the writing, the checksum in File Header represents the modified page, while the checksum in File Trailer represents the original page, and the difference between the two means that there is a mistake in synchronization.

The last 4 bytes represent the corresponding log sequence location (LSN) when the page was last modified.

This section is also used to verify the integrity of the page, but we haven't said what LSN means yet, so we can ignore this property for a while.

This File Trailer is similar to File Header in that it is common to all types of pages.

Summary

InnoDB designs different types of pages for different purposes, and the pages used to store records are called data pages.

A data page can be roughly divided into seven parts, namely

File Header, which represents some general information on the page, accounts for a fixed 38 bytes.

Page Header, which represents some information specific to the data page, accounting for a fixed 56 bytes.

Infimum + Supremum, two virtual pseudo records, represent the smallest and largest records in the page, respectively, accounting for a fixed 26 bytes.

User Records: the part that actually stores the records we insert, the size is not fixed.

Free Space: the unused part of the page, whose size is uncertain.

Page Directory: the relative position of some records in the page, that is, the address offset of each slot in the page, is not fixed, and the more records are inserted, the more space this part takes up.

File Trailer: the part used to check the integrity of a page, occupying a fixed 8 bytes.

There is a next_record attribute in the header information of each record, so that all records in the page are concatenated into a single linked list.

InnoDB divides the records in the page into several groups, and the address offset of the last record in each group is stored in Page Directory as a slot, so it is very fast to find records based on the primary key in a page, which is divided into two steps:

The slot in which the record is located is determined by dichotomy.

Traverse each record in the group in which the slot is located through the next_record property of the record.

The File Header section of each data page is numbered by the previous and next pages, so all data pages form a double-linked list.

In order to ensure the integrity of the page synchronized from memory to disk, the checksum of the data in the page and the LSN value corresponding to the last modification of the page will be stored at the head and tail of the page. If the checksum and LSN value verification of the head and tail is not successful, it means that there is something wrong with the synchronization process.

After reading the above, have you mastered the principle of InnoDB data page in MySQL? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.