The original address: blog. Jcole. Us / 2013/01/03 /…

In the data storage model, there is usually the concept of “space”, which is called “table space” in MySQL and sometimes also called “file space” in InnoDB. A space may consist of multiple actual files in an operating system (e.g. Ibdata1, IBdatA2, and so on) that are really just one logical file – multiple literary files are treated as one connected file.

Each InnoDB space is assigned a 32-bit unsigned integer space ID, which is used to refer to the space in different places. InnoDB always has a “system space” whose space ID is 0. The system space is used to hold records of InnoDB’s set of metadata. With MySQL, InnoDB currently only supports additional space in the form of a “one table, one file” space, which creates.ibd files for each MySQL table. Internally, the.ibd file is actually a complete space that can hold multiple tables, but in MySQL’s implementation, it can only contain one table.

page

Each space is shred into pages, typically 16 KiB per page (this can also be modified by specifying UNIV_PAGE_SIZE at compile time, or by enabling InnoDB compression). Pages in space are assigned a 32-bit page number called an offset, which is actually the page offset from the beginning of the spatial address. So, page 0 is at file offset 0, page 1 is at file offset 16384, and so on. Some of you may recall that InnoDB’s data size limit is 64 TiB, which is actually a per-space limit. Because the page number is a 32-bit unsigned integer and the default page size is 16 KiB, the maximum space size is 2^32 * 16 KiB = 64 TiB

The structure of the page is as follows:

Each page has a 38-byte FIL header and a FIL tail (the name FIL actually comes from the abbreviation for “file”). The header contains a field that represents the page type, which determines the structure of the rest of the page. The structure of the FIL head and FIL tail is as follows:

The FIL header and tail contain the following structures:

  • Page type (2 bytes) : This is important for parsing the rest of the page data. Many modules and scenarios need to allocate page storage, including file space management, scope management, transaction systems, data fields, Undo log, blobs data and index and table data.
  • Space ID (4 bytes)
  • Page number (4 bytes) : The page number is saved when the page is initialized. Checking that the page number saved in this field matches the page number read against the file offset helps to indicate whether the reading was correct. Also, if the field is initialized, the page is initialized as well
  • Checksum (4 bytes) and old version checksum (4 bytes)
  • Pointer to previous page (4 bytes) and next page (4 bytes) : This can be used to build bidirectional linked lists and index pages where all pages are linked at the same level, thus improving the efficiency of index full scans. But there are many page types that don’t use these fields.
  • The header stores the LSN (log sequence number, 8 bytes) corresponding to the most recent change, and the lower 32 bits of the sequence number are also stored in the tail.
  • The global maximum log sequence number (known as Flush LSN, 8 bytes). The real sequence number is stored only on page 0 of space 0. The value of this field is 0 on all other pages, which means that the field is reused on page 0 of space 0. This allows you to modify only one field globally.

spacefile

A spatial file is an aggregated link of many pages (up to 2^32). For more efficient management, pages are aggregated into blocks of 1 MiB size (64 contiguous pages; the default page size is 16 KiB). This block is called an extent. Many structures allocate pages in a space only through reference sections

InnoDB needs to do some metadata logging to keep track of all pages, extents and Spaces themselves.

The first page in the space is FSP_HDR(file space header page). The FSP_HDR page contains an FSP structure that records data such as the size of the space, the list of free extols, shards, and full extols (I’ll write a detailed introduction to free space management in the future). One page of FSP_HDR has enough space to hold only 256 extences (16,384 pages, 256 MiB) of information, so after every 16,384 pages, additional space is required to record the information of these pages. The structure of the XDES page is the same as that of the FSP_HDR page, except that the storage occupied by FSP in XDES is filled with zeros. These additional pages are automatically allocated as the spatial file grows.

The INODE page is used to hold a list of file segments that contain a set of extents and an array of extents that are only allocated individually. Each INDOE page can hold 85 INODE elements, and each index requires two INODE elements (I’ll write a more detailed article on INDOE element contents and file areas in the future).

The IBUF_BITMAP page holds information about the insert cache and is beyond the scope of this series.

systemspace

System space (space 0) is special and contains many pages assigned by fixed page numbers to store the vast amount of information that is critical to InnoDB operations. The system space, like any other space, requires the FSP_HDR, IBUF_BITMAP, and Inode pages as the first three pages. After that, it’s a little different from the other pages.

  • Page 3,SYSType: Header information related to the insert cache.
  • Page 4,INDEXType: root page of the index structure used to insert buffers.
  • Page 5,TRX_SYSType: Information related to the operation of the InnoDB transaction system, such as the latest transaction ID, MySQL binary log information, and the location of the double-write buffer range.
  • On page 6,SYSType: first rollback section page. Allocate additional pages (or entire extents) as needed to store rollback segment data.
  • Page 7,SYSType: Header information related to the data dictionary, containing the root page number of the indexes that make up the data dictionary. This information can be found in any other index (table) because their root page numbers are stored in the data dictionary.
  • Pages 64-127: The first block (64 pages) in the double-write buffer, an important part of InnoDB’s recovery mechanism
  • Pages 128-191: Block 2 in the double-write buffer

Other pages are allocated to indexes, rollback segments, undo logs, and so on, as needed.

Each tablespace file

InnoDB provides a “one file per table” mode, which creates a file (actually a space, as described above) for each MySQL table. Perhaps “one space per table” would be more appropriate. Each table creates an.ibd file, which has the following structure:

Ignoring quick index adding (that is, adding indexes at run time), after the required three initial pages, the next page allocated in space will be the root page of each index in the table, in the order of indexes defined in table creation. Page 3 will be the root of the clustered index, page 4 will be the root of the first secondary index, and so on.

Since most of InnoDB’s metadata structures are stored in system space, most pages allocated in “one space per table” are of type INDEX and store table data.