MySQL的InnoDB存储引擎：从Page到Extent的物理存储结构与空间管理 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

MySQL InnoDB存储引擎：从Page到Extent的物理存储结构与空间管理

大家好，今天我们来深入探讨MySQL InnoDB存储引擎的物理存储结构和空间管理机制。理解这些底层细节对于优化数据库性能、排查故障以及进行容量规划至关重要。

一、Page（页）：InnoDB的最小存储单元

InnoDB存储引擎以页（Page）作为磁盘管理的最小单元。默认情况下，一个Page的大小是16KB。所有的数据、索引、undo log等都存储在Page中。Page的结构可以概括为：

Header	Data Area	Free Space	Trailer
控制信息（56B）	实际数据存储区	未使用的空间	校验和（8B）

Header: 包含页的类型（如数据页、索引页）、页号、上一页和下一页的指针等控制信息。这些信息对于InnoDB管理Page和构建B+树索引至关重要。
Data Area: 实际存储的数据行或索引项。数据行采用行格式（Row Format）存储，例如REDUNDANT, COMPACT, DYNAMIC, COMPRESSED。不同行格式对存储空间利用率和性能有不同的影响。
Free Space: 新数据插入时，会从Free Space分配空间。当Free Space不足时，可能需要进行Page分裂。
Trailer: 包含页的校验和（checksum）和LSN（Log Sequence Number）。校验和用于检测页是否损坏，LSN用于崩溃恢复。

Page的类型：

InnoDB定义了多种Page类型，用于存储不同类型的数据。常见的Page类型包括：

数据页（B-tree Node Page）： 存储表中的数据行。
索引页（B-tree Node Page）： 存储索引记录，指向数据页或其他索引页。
Undo页（Undo Log Page）： 存储Undo Log，用于事务回滚。
Insert Buffer Bitmap页: 用于管理Insert Buffer。
System页: 存储系统信息，如数据库的版本和数据字典信息。
BLOB页: 存储BLOB类型的数据。

Page结构的代码示例（伪代码，展示概念）：

struct PageHeader {
    uint32_t page_no;           // 页号
    uint32_t prev_page;         // 上一页的页号
    uint32_t next_page;         // 下一页的页号
    uint16_t page_type;         // 页类型
    uint16_t page_latch;        // 页锁信息
    // ... 更多控制信息
};

struct PageTrailer {
    uint64_t checksum;         // 页校验和
    uint64_t lsn;              // 日志序列号
};

struct Page {
    PageHeader header;
    char data[16384 - sizeof(PageHeader) - sizeof(PageTrailer)]; // 数据区域
    PageTrailer trailer;
};

二、Extent（区）：连续Page的集合

为了更好地管理磁盘空间，InnoDB引入了Extent（区）的概念。一个Extent由若干个连续的Page组成。默认情况下，一个Extent包含64个连续的Page，因此一个Extent的大小是 64 * 16KB = 1MB。

Extent的作用:

空间分配： InnoDB以Extent为单位进行空间分配，减少了磁盘碎片。
顺序I/O： 连续的Page存储在同一个Extent中，可以提高顺序I/O的性能。

Extent的类型:

数据区: 存储表数据和索引。
Undo区: 存储Undo Log。
临时区: 用于临时表的存储。

初始Extent与后续Extent:

InnoDB在创建表时，会分配一些初始Extent。当这些Extent的空间用完后，InnoDB会根据需要分配新的Extent。对于小表，InnoDB可能会采用共享Extent的方式，即多个小表共享一个Extent。对于大表，InnoDB通常会为每个表分配独立的Extent。

三、Segment（段）：一系列Extent的集合

Segment是更高层次的逻辑概念，它代表了特定类型的数据的集合。例如，一个表的数据存储在一个Segment中，表的索引存储在另一个Segment中。Segment由一系列Extent组成，这些Extent可能是不连续的。

Segment的类型:

数据段（Data Segment）： 存储表中的数据行。
索引段（Index Segment）： 存储表的索引数据。
Undo段（Undo Segment）： 存储Undo Log。
Rollback 段(Rollback Segment): 存储回滚信息。

Segment与Extent的关系:

一个Segment由多个Extent组成，这些Extent可能是不连续的。InnoDB通过链表等数据结构来管理Segment中的Extent。当Segment的空间不足时，InnoDB会分配新的Extent到该Segment。

四、Tablespace（表空间）：存储数据文件的逻辑容器

Tablespace是InnoDB存储引擎中的最高层次的逻辑容器。它用于存储表、索引和其他数据库对象的数据。Tablespace包含一个或多个数据文件。

Tablespace的类型:

系统表空间（System Tablespace）： 包含InnoDB的数据字典、Undo Log、Insert Buffer等系统信息。系统表空间默认的文件名为ibdata1、ibdata2等，可以配置多个数据文件。
独立表空间（File-per-table Tablespace）： 每个表对应一个独立的表空间。独立表空间的文件名为表名.ibd。使用独立表空间可以提高表的备份和恢复效率，并且更容易回收空间。
通用表空间（General Tablespace）： 可以包含多个表。通用表空间允许将多个表组织在一个文件中，但管理相对复杂。
Undo表空间（Undo Tablespace）： 专门用于存储Undo Log，可以独立管理Undo Log的空间。
临时表空间（Temporary Tablespace）： 用于存储临时表的数据。

Tablespace与数据文件的关系:

一个Tablespace可以包含一个或多个数据文件。InnoDB将数据文件视为连续的字节流，并将数据组织成Page、Extent和Segment。

五、InnoDB的空间管理

InnoDB的空间管理主要涉及以下几个方面：

空间分配： InnoDB以Extent为单位进行空间分配。当需要分配空间时，InnoDB会从Free List中查找可用的Extent。如果Free List为空，InnoDB会尝试扩展数据文件。
空间回收： 当表被删除或索引被删除时，InnoDB会回收相应的空间，并将这些空间添加到Free List中。
碎片整理： 随着数据的不断插入和删除，可能会产生磁盘碎片。InnoDB提供了一些机制来减少磁盘碎片，例如OPTIMIZE TABLE命令。

InnoDB的空间管理数据结构：

Free List： 用于管理空闲的Extent。
Inode List： 用于管理Segment的元数据信息。
Full Extent List： 用于管理完全空闲的Extent。
Partially Full Extent List： 用于管理部分空闲的Extent。

空间分配算法：

InnoDB采用一种基于B-tree的索引结构来管理Free List。这种索引结构可以快速查找可用的Extent。InnoDB会优先选择Partially Full Extent List中的Extent，以提高空间利用率。

空间回收算法：

当表被删除或索引被删除时，InnoDB会将相应的Extent添加到Free List中。InnoDB会尝试合并相邻的空闲Extent，以减少磁盘碎片。

六、代码示例：查看InnoDB空间使用情况

可以使用SQL语句来查看InnoDB的空间使用情况。

-- 查看系统表空间的使用情况
SELECT
    TABLESPACE_NAME,
    FILE_NAME,
    ENGINE,
    ROUND(SUM(DATA_LENGTH) / 1024 / 1024, 2) AS data_size_mb,
    ROUND(SUM(INDEX_LENGTH) / 1024 / 1024, 2) AS index_size_mb,
    ROUND(SUM(DATA_FREE) / 1024 / 1024, 2) AS free_size_mb
FROM
    information_schema.TABLES
WHERE
    TABLE_SCHEMA = 'your_database_name'  -- 替换为你的数据库名
    AND ENGINE = 'InnoDB'
GROUP BY
    TABLESPACE_NAME,
    FILE_NAME,
    ENGINE
ORDER BY
    data_size_mb DESC;

-- 查看独立表空间的使用情况
SELECT
    TABLE_NAME,
    TABLESPACE_NAME,
    ENGINE,
    ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_size_mb,
    ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS index_size_mb,
    ROUND(DATA_FREE / 1024 / 1024, 2) AS free_size_mb
FROM
    information_schema.TABLES
WHERE
    TABLE_SCHEMA = 'your_database_name'  -- 替换为你的数据库名
    AND ENGINE = 'InnoDB'
    AND TABLESPACE_NAME != 'innodb_system'
ORDER BY
    data_size_mb DESC;

这些SQL语句可以帮助你了解数据库的空间使用情况，并根据需要进行空间优化。

七、InnoDB物理存储结构总结

层次	概念	大小（默认）	说明
Page	页	16KB	InnoDB最小的存储单元。包含Header、Data Area、Free Space和Trailer。存储数据行、索引项、Undo Log等。
Extent	区	1MB	由64个连续的Page组成。用于空间分配和提高顺序I/O性能。
Segment	段	动态	逻辑概念，代表特定类型的数据的集合，如数据段、索引段。由一系列Extent组成。
Tablespace	表空间	动态	存储数据文件的逻辑容器。包含一个或多个数据文件。分为系统表空间、独立表空间、通用表空间等。

八、理解物理存储结构的重要性

理解InnoDB的物理存储结构对于数据库管理员和开发人员来说至关重要。它可以帮助你：

优化数据库性能： 通过选择合适的行格式、索引类型和表空间类型，可以提高数据库的读写性能。
排查数据库故障： 当数据库出现性能问题或数据损坏时，可以根据物理存储结构来定位问题。
进行容量规划： 了解数据库的空间使用情况，可以更好地进行容量规划，避免空间不足的问题。
理解InnoDB的内部机制： 深入理解InnoDB的物理存储结构，可以更好地理解InnoDB的内部机制，从而更好地利用InnoDB的特性。

九、InnoDB的存储管理策略：优化数据库性能的关键

了解InnoDB的存储管理策略，包括数据页的结构，索引的管理以及空间分配与回收机制，是进行数据库性能优化的基础。掌握这些知识，能帮助我们更好地设计表结构、选择合适的索引，并有效地管理磁盘空间，从而提升数据库的整体性能。

MySQL InnoDB存储引擎：从Page到Extent的物理存储结构与空间管理

发表回复 取消回复

发表回复取消回复