表空间是InnoDB组织物理文件与内存页的逻辑容器，对应ibdata1（系统）、.ibd（独立/通用）、undo_*.ibu（撤销）、ibtmp1（临时）等文件，不包括redo log和binlog。

表空间 是 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 启不起来，连错误日志都打不出来。