表空间与独立表空间

做的事：同样的数据，一份放独立表空间，一份放共享表空间

代码SELECT @@innodb_file_per_table; -- 本机真实是1（默认开启） CREATE TABLE uncomp_test (...) ; -- 默认走独立表空间 CREATE TABLE shared_test (...) TABLESPACE=innodb_system; -- 显式指定共享表空间

验证：独立表空间的表，DROP之后文件真实立刻消失

实测 · 本机磁盘真实变化

DROP之前：  /opt/homebrew/var/mysql/mysqllab/uncomp_test.ibd  存在，393216字节
DROP TABLE uncomp_test;
DROP之后：  该文件真实不存在了

独立表空间(innodb_file_per_table=ON，每张表一个独立的.ibd文件)的设计，让"删表回收磁盘空间"这件事变得真实简单直接——DROP TABLE真实就是删掉这个文件，操作系统立刻能看到这块磁盘空间被真实释放。

验证：共享表空间的表，压根没有自己的文件，DROP也不还空间

实测 · 本机磁盘真实变化

$ ls mysqllab/shared_test.ibd
（真实不存在——这张表的数据存在共享的ibdata1里，没有独立文件）

创建shared_test、插入数据前：  ibdata1 = 79691776 字节
插入约500KB数据之后：          ibdata1 = 79691776 字节  （真实没变）
DROP TABLE shared_test 之后：   ibdata1 = 79691776 字节  （真实还是没变）

这个对比真实揭示了两种表空间模式最大的实际差异：独立表空间下，一张表占用的磁盘空间和它对应的.ibd文件一一对应，删表即刻回收；共享表空间(ibdata1，这也是MySQL 5.5之前唯一的存储方式)下，所有走共享表空间的表都混在同一个文件里，这个文件只会真实变大、几乎不会自动收缩——哪怕把里面的表全部删光，ibdata1已经占用的磁盘空间也不会自动还给操作系统，除非手动重建整个实例。这正是MySQL 5.6把innodb_file_per_table默认值改成ON、5.7之后连系统表本身也逐步搬出共享表空间的真实原因——独立表空间在空间管理上明显更友好。

分步演示：两种表空间的删表结果对比

每一步都是本文上面用真实磁盘文件跑出来的原始结果。

删表之后，谁真的把空间还给了操作系统

这一步新验证的表空间类型

本文用到的工具

本机 MySQL 26.7.0（InnoDB），innodb_file_per_table真实是默认开启的
真实对比独立表空间(.ibd文件)和共享表空间(ibdata1)在DROP TABLE后的磁盘表现

下一篇 · MYSQL / INNODB 72

簇索引页分裂