MySQL的数据最终都要落到磁盘上，而承载这些数据的载体就是表空间和数据文件。不少人对ibdata1这个文件又爱又恨：它有时候只有十几MB，有时候却能膨胀到几十GB，删了表也不见缩小。要理解这些现象，就得先搞清楚InnoDB的存储架构，明白表空间、段、区、页之间的层级关系，再来谈具体的管理和运维手段。
一、InnoDB存储架构：表空间到底是什么
InnoDB是MySQL默认的存储引擎（从5.5版本开始），它的存储逻辑自上而下可以分成几层：表空间、段、区、页。表空间是最顶层的逻辑容器，物理上对应一个或多个磁盘文件。每个表空间由若干个段组成，段又由若干个区构成，一个区默认是1MB，包含64个16KB的页，页是InnoDB管理数据的最小单位，也就是我们常说的B+树节点。
表空间分为两大阵营。第一种是系统表空间，在早期版本里是默认选择，所有表的数据都存放在共享的ibdata1文件中。第二种是独立表空间，也就是file-per-table模式，从5.6.6版本开始默认开启，每张表对应一个自己的.ibd文件。除这两者之外，还有通用表空间、临时表空间和Undo表空间，各自承担不同职责。
系统表空间除了存表数据，还保存着数据字典、Change Buffer、双写缓冲区等重要结构，所以即使开启了独立表空间，ibdata1也不会消失，只是不再无限增长而已。理解这一点非常重要，很多误删ibdata1导致库无法启动的事故，根源就是不清楚它里面装的不只是业务数据。
二、各类表空间的作用与配置方法
系统表空间由参数innodb_data_file_path控制，默认值是ibdata1:12M:autoextend，表示初始12MB并自动扩展。如果想让ibdata1固定大小或者增加新文件，可以在my.cnf中这样配置：
[mysqld] innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
注意一旦设定了固定大小，后续修改必须与磁盘上实际的文件大小严格一致，否则实例会启动失败。这也是运维中一个高频踩坑点：改配置前先确认ibdata1当前的实际字节数。
独立表空间由innodb_file_per_table控制，5.6.6之后默认为ON。开启后每张表在数据库同名目录下生成一个.ibd文件，好处显而易见：单表空间可以独立回收、可以方便地通过传输表空间做数据迁移、truncate表时直接重建文件速度更快。判断当前是否开启，执行下面这条命令即可：
SHOW VARIABLES LIKE 'innodb_file_per_table';
通用表空间则类似一个自定义的共享容器，可以用一条CREATE TABLESPACE语句创建，然后让多张表指定存入其中，适合需要把一批小表集中管理的场景。临时表空间由innodb_temp_data_file_path控制，存放临时表和排序中间结果；Undo表空间存放回滚日志，从8.0版本开始支持独立的undo文件并且可以在线截断回收，这在以前的老版本里是做不到的。
三、日常管理：查看、扩容与空间回收
查看表空间的使用情况是最基础的运维操作。要了解每个ibd文件占用了多少空间，可以直接查询information_schema.INNODB_TABLESPACES，或者用更直观的方式看文件层面：
SELECT table_schema, table_name,
ROUND(data_length/1024/1024, 2) AS data_mb,
ROUND(index_length/1024/1024, 2) AS index_mb
FROM information_schema.tables
WHERE engine = 'InnoDB'
ORDER BY data_length DESC
LIMIT 10;
这里要特别提醒一句，如果你的表数量达到几万甚至几十万张，直接全量查询information_schema.tables会非常慢，因为它要逐个打开frm或者sd文件统计信息，可能导致实例卡顿。生产环境建议限定table_schema缩小范围，或者开启innodb_stats_on_metadata相关的控制。
关于空间回收，最经典的问题是删除大量数据后磁盘空间没有释放。原因在于InnoDB的删除只是标记删除，页内的空闲空间会被复用，但文件本身不会自动收缩。如果确实需要把空间还给操作系统，独立表空间下的标准做法是在业务低峰期执行重建：
-- 在线重建表并回收空间 ALTER TABLE orders ENGINE=InnoDB; -- 或者使用更推荐的方式 OPTIMIZE TABLE orders;
这两条命令本质上都会重建表空间文件，期间需要足够的临时磁盘空间来存放新文件，操作前务必评估剩余容量。对于系统表空间，很遗憾它不支持收缩，ibdata1一旦膨胀就无法逆转，唯一的办法是逻辑导出全部数据，删除ibdata1后重新导入，这也就是为什么强烈建议保持file-per-table开启。
磁盘扩容方面，如果ibd文件所在的分区快满了，云环境下最简单的方案是扩磁盘再扩文件系统。另一个思路是利用软链接把大表目录指到独立的数据盘上，创建表时指定DATA DIRECTORY也可以让表空间直接建在指定路径：
CREATE TABLE big_log (
id BIGINT PRIMARY KEY,
content TEXT,
created_at DATETIME
) DATA DIRECTORY = '/data2/bigtables/';
总的来说，管理MySQL表空间的核心思路是：坚持独立表空间模式、监控大表的增长趋势、理解共享表空间不可收缩的特性、在空间回收时选择合适的重建时机。把这些原则落实到日常巡检中，基本就能避免绝大多数和磁盘空间相关的生产事故。