表空间是 InnoDB 存储引擎中数据存储的逻辑容器，不是文件夹、也不是数据库，而是把物理磁盘文件（如
ibdata1、
xxx.ibd）和内存中页（page）、区（extent）、段（segment）组织起来的一套抽象结构。它直接决定了你的数据怎么落盘、怎么读取、怎么备份、甚至崩溃后能不能恢复。
表空间到底对应哪些物理文件？
不同类型的表空间，背后是完全不同的文件形态：
系统表空间：默认只有一个文件
ibdata1（有时带
ibdata2等），存着数据字典、undo 日志（旧版本）、change buffer、还有可能包含用户表数据（如果没开
innodb_file_per_table）
独立表空间：每个
CREATE TABLE ... ENGINE=InnoDB表默认生成一个
数据库名/表名.ibd文件（例如
/var/lib/mysql/test/t_user.ibd），表数据 + 索引全在里面
通用表空间：由
CREATE TABLESPACE ts_name ADD DATAFILE 'ts_name.ibd'创建，可手动把多个表
ALTER TABLE t1 TABLESPACE ts_name迁入，共享一个
.ibd文件
撤销表空间：MySQL 8.0+ 默认启用多个独立
undo_001.ibu文件，用于事务回滚，可配置为自动扩展或固定大小
临时表空间：通常是
ibtmp1（位于
innodb_temp_data_file_path指定路径），只存
CREATE TEMPORARY TABLE和内部排序/聚合产生的临时数据
⚠️ 注意：
ib_logfile0/1（redo log）和
mysql-bin.*（binlog）不属于表空间，它们是日志系统独立管理的文件。
为什么默认开启 innodb_file_per_table
？
这是 MySQL 5.6+ 的默认值（
ON），核心原因就三个字：可回收。 关掉它（
OFF）：所有表都往
ibdata1里塞 →
DROP TABLE后
ibdata1永不缩小，磁盘空间无法释放 开启它（
ON）：每张表一个
.ibd→
DROP TABLE后文件直接删除，空间立刻归还文件系统 还能单独对某张大表做
OPTIMIZE TABLE或
ALTER TABLE ... REBUILD来收缩空间，不影响其他表
如果你发现
ibdata1膨胀到几百 GB 却删不掉，八成是早期建库时没开这个选项，且已有大量表在系统表空间里 —— 这种情况迁移成本极高，需导出再重建。
表空间里的数据到底是怎么组织的？
InnoDB 不是以“行”或“列”为单位存数据，而是按层级结构组织：
页（Page）：最小 I/O 单位，默认16KB（由
innodb_page_size决定），
INDEX类型页存 B+ 树节点（含聚簇索引/二级索引），
BLOB页存溢出的大字段 区（Extent）：连续 64 个页 =
1MB，分配空间时以区为单位（避免页碎片导致随机 IO） 段（Segment）：逻辑概念，比如一张表的聚簇索引分两个段 ——
叶子节点段（存真实记录）和
非叶子节点段（存目录页），各自从不同区申请空间
所以你执行
SELECT * FROM t LIMIT 1，InnoDB 实际上是从表空间里找到聚簇索引的根页 → 定位到某个叶子区 → 加载整页（16KB）进 Buffer Pool → 再从页里解析出那一条记录。不是“读一行”，而是“读一页”。
常见误操作与修复场景
表空间问题往往表现为错误信息直击要害，但根源常被忽略：
ERROR 1114 (HY000): The table 't' is full：不是磁盘满，而是该表所在表空间（比如
t.ibd）已达到
innodb_data_file_path设置的上限，或文件系统满。查
df -h和
ls -lh *.ibd
Tablespace is missing for table `db`.`t`：
.ibd文件被误删，但
frm还在 →
ALTER TABLE t DISCARD TABLESPACE+ 手动拷回
.ibd+
IMPORT TABLESPACE（需严格匹配表结构、checksum、server_uuid）
InnoDB: Failing assertion: page_no == 0：表空间头损坏（
FSP_HDR页异常），
mysqlcheck --repair通常无效，得靠备份恢复；预防手段是开启
innodb_checksum_algorithm=crc32+ 定期校验
真正棘手的从来不是“怎么扩容”，而是“哪张表在哪个表空间里、它的物理文件是否还在、有没有被硬链接或 mount bind 遮蔽”——这些细节一漏，
mysqld启不起来，连错误日志都打不出来。
