InnoDB 引擎并不直接把数据随意扔在磁盘上，而是将表、索引、日志等对象组织在一个或多个表空间（Tablespace） 中。从逻辑上看，表空间是 InnoDB 存储的最高层抽象；从物理上看，每个表空间代表磁盘上一个或多个文件。
掌握表空间的概念和配置方式，不仅能帮你合理规划磁盘使用，还能在迁移数据库、回收空间、排查磁盘占用时做到心中有数。
在 MySQL 8.0 中，InnoDB 主要使用以下几种表空间类型：
- 系统表空间（System Tablespace）
- 独立表空间（File-Per-Table Tablespace）
- 撤销表空间（Undo Tablespaces）
- 通用表空间（General Tablespaces）
- 临时表空间（Temporary Tablespaces）
其中前三种是核心，也是本节的重点。
1. 系统表空间：InnoDB 的“大管家”
系统表空间对应磁盘上一个或多个文件，最典型的就是数据目录下的 ibdata1。在早期 MySQL 版本（5.6 及之前），ibdata1 几乎包揽了一切：
- InnoDB 数据字典（表的元信息）
- Change Buffer（写缓冲）
- Double Write Buffer（双写缓冲）
- Undo Log（回滚日志）
这个设计有一个明显弊端：ibdata1 会随着数据写入不断膨胀，而且只会增大不会自动收缩。一旦表被删除或回滚段被清理，文件内部的空闲空间不会被释放回操作系统，成了永久的磁盘占用。
从 MySQL 5.7 开始，InnoDB 逐步将内部组件从系统表空间剥离。到 MySQL 8.0 时，数据字典已经迁移到独立的 mysql.ibd 文件，Undo Log 也默认使用独立的撤销表空间，系统表空间只负责 Change Buffer 和 Double Write Buffer，负担大大减轻。
对于系统表空间，你需要关注两个实际操作点：
- 配置
innodb_data_file_path：此参数决定了系统表空间的文件名、初始大小以及是否自动扩展。典型配置如ibdata1:12M:autoextend，表示ibdata1初始 12MB，空间不足时自动扩展。生产环境建议适当调大初始值（如 1G），避免频繁自动扩展的 I/O 抖动。 - 不用担心
ibdata1过大：在 8.0 里，ibdata1大小主要由 Change Buffer 和 Double Write Buffer 决定，这两个都不会无限制增长，通常维持在几百 MB 到几 GB 之间，合理范围内无需刻意处理。
2. 独立表空间：每表一文件的灵活管理
独立表空间由参数 innodb_file_per_table 控制，默认在 MySQL 5.6 及之后的版本中均为 ON。
开启此功能后，每一个 InnoDB 表都会在对应的数据库目录下生成一个 .ibd 文件，例如表 mydb.orders 对应文件 mydb/orders.ibd。该文件内包含表数据、索引以及一些本地 undo 信息。
独立表空间的实用价值非常高：
- 空间回收：当你执行
TRUNCATE TABLE或DROP TABLE时，对应的.ibd文件会直接被操作系统删除，磁盘空间立即可用。相比之下，若表数据放在系统表空间，删除表只会标记内部空间为“可重用”，文件大小却不会缩减。 - 数据迁移：可以利用 可传输表空间（Transportable Tablespace） 特性，将
.ibd文件连同表结构从一台服务器快速迁移到另一台，比逻辑导出导入快得多。这是大型表数据迁移的常用方案。 - 备份与恢复灵活性：物理备份工具（如 XtraBackup）可以在表级别进行备份和恢复，且独立表空间使得增量备份和单表恢复更加方便。
- 隔离性：一张表的损坏不会影响其他表，而在系统表空间里，一个页损坏可能导致整个
ibdata1文件内的所有表都受影响。
使用独立表空间时有几个注意事项：
- 每表一个文件，意味着如果数据库有大量表（比如分库分表后上千张表），会产生大量文件句柄，需要适当调高操作系统的
open_files_limit参数。 - 独立表空间文件也会随时间膨胀（尤其是频繁更新和删除操作后），虽然可以通过重建表（
OPTIMIZE TABLE）来收缩，但操作本身会锁表并产生大量 I/O，需在业务低峰期执行。 - 参数
innodb_file_per_table可以在线动态修改，但只影响新创建的表。已有表仍然按创建时的表空间模式存储，不会自动转换。
一个实用建议：生产环境强烈建议保持 innodb_file_per_table = ON。只有极少数特殊场景（比如你要使用共享表空间的高级特性）才关掉它，否则带来的空间释放和迁移便利性远大于潜在的文件数量开销。
3. 撤销表空间：专门管理 Undo Log
撤销表空间用于存放 Undo Log（回滚日志），这是实现事务原子性回滚和 MVCC 多版本读的关键数据。当事务修改一行数据时，修改前的旧值会被写入 Undo Log，保存在撤销表空间中。
在非常古老的 MySQL 版本里，Undo Log 是存储在系统表空间内的，这导致系统表空间膨胀且无法回收。从 MySQL 5.6 开始，支持将 Undo Log 从系统表空间中分离出来，使用独立的表空间文件。到了 MySQL 8.0，Undo Log 默认就存放在独立的撤销表空间中，通常以 undo_001、undo_002 等命名，位于数据目录下。
撤销表空间的几个核心行为需要了解：
- 自动管理：MySQL 8.0 默认创建两个撤销表空间文件，InnoDB 会根据参数
innodb_undo_tablespaces（默认 2）在启动时创建相应数量的文件。这些文件在表空间不足时会自动扩展（受innodb_max_undo_log_size限制）。 - 截断（Truncation）：Undo Log 有生命周期，当事务提交且不再需要用于 MVCC 读取后，对应的 Undo 页就过期了。InnoDB 后台会定期回收这些页，并将撤销表空间“截断”到合理大小，避免空间无限增长。这个特性是 8.0 带来的很大改进，不再需要手动维护。
- 临时和独立分布：临时表（
CREATE TEMPORARY TABLE）使用的 Undo Log 会存放在全局临时表空间中（ibtmp1），普通事务的回滚则在使用独立的撤销表空间。这进一步隔离了不同场景下的空间使用。
对于撤销表空间的日常运维，基本不需要人为干预，它已经高度自动化。你只需要注意不要随意删除 undo_* 文件，并且 innodb_undo_directory 可以指定存放路径，便于将 Undo 写入高性能的磁盘（如 SSD），提升事务吞吐量。
补充：通用表空间与临时表空间
除了上述三种核心表空间，还有两个在实际工作里偶尔会遇见的类型，作为补充了解：
- 通用表空间（General Tablespace）：使用
CREATE TABLESPACE语法创建，可以跨数据库为多个表共享同一组数据文件。它主要用于管理大量分区表、控制文件数量或实施更细粒度的磁盘布局。一般业务开发中较少使用。 - 临时表空间（Temporary Tablespace）：专门存放临时表、内部排序、哈希连接产生的临时数据，对应文件为
ibtmp1。重启 MySQL 时该文件会被重建，所有临时数据丢失。如果需要调整大小，只能通过重启并删除旧文件后重新创建的方式。
本节要点回顾：
- 系统表空间 (
ibdata1) 在 8.0 中职责已大幅缩减，主要维护 Change Buffer 和 Double Write Buffer。 - 独立表空间 (每表
.ibd) 是现代 MySQL 的默认选择，便于空间回收、数据迁移，生产环境务必保持开启。 - 撤销表空间在 8.0 中自动管理，负责 Undo Log 存储和回收，基本无需人工介入。
理解这三类表空间的定位，你就能明白为什么有时候磁盘突然被占满（大事务产生大量 Undo），为什么 ibdata1 不再无限变大，以及为什么执行 DROP TABLE 能立刻释放空间。这些都是 DBA 日常工作中会反复接触的实在知识。