MySQL表空间与ibdata1膨胀处理：独立表空间、碎片整理与磁盘回收

发布时间：2026-09-17 04:31 更新时间：2026-09-17 04:31 阅读量：0

很多站长在服务器磁盘告警时会遇到一个奇怪现象：用 du -sh 看数据目录，ibdata1 这个文件动辄几十 GB，而业务库里的表加起来远没有这么大；更让人困惑的是，明明 DELETE 掉了几百万行数据，磁盘空间一点没释放。这类问题的根源，大多出在 InnoDB 的表空间管理方式上。本文把 innodb_file_per_table、共享表空间和碎片整理这几件事讲清楚，让你知道什么情况下能回收磁盘、什么情况下只能另想办法。

ibdata1 为什么会一直变大

InnoDB 的数据存放方式由参数 innodb_file_per_table 决定。当它为 OFF 时，所有用户表的表数据、索引、回滚段（undo）、以及数据字典等信息，全部塞进共享表空间，也就是数据目录下的 ibdata1（可能还有 ibdata2、ibdata3……）。共享表空间的特点是：只增不减。你删掉一张几百 GB 的表，文件不会自动缩小，那部分空间只是被标记为可复用，留给后续插入的数据使用。

从 MySQL 5.6.6 起，innodb_file_per_table 默认就是 ON，每张表会有一个独立的 .ibd 文件。但即使开了独立表空间，ibdata1 依然存在，它仍然承载着 undo 日志、change buffer、双写缓冲（doublewrite buffer）等共享信息，以及那些在参数为 OFF 时期创建的老表的数据。所以看到 ibdata1 很大，先别急着删文件——直接删除 ibdata1 会导致数据库无法启动。

先确认当前配置和表空间分布：

-- 查看是否开启独立表空间
SHOW VARIABLES LIKE 'innodb_file_per_table';

-- 查看各库表的数据与索引占用（按大小排序）
SELECT table_schema, table_name,
       ROUND(data_length/1024/1024, 2) AS data_mb,
       ROUND(index_length/1024/1024, 2) AS index_mb,
       ROUND(data_free/1024/1024, 2) AS free_mb
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys')
ORDER BY data_length + index_length DESC
LIMIT 20;

其中 data_free 表示表内已经分配但未使用的空间，它可以粗略反映碎片程度。如果某张表 data_free 很大，说明里面确实有大量空洞，值得做一次整理。

开启独立表空间与迁移已有表

如果查询发现 innodb_file_per_table 是 OFF，建议改为 ON。这个参数是动态的，可以在线修改，但要注意：它只对之后新建的表生效，老表仍然待在共享表空间里。

SET GLOBAL innodb_file_per_table = ON;

想让老表也搬到独立表空间，需要对每张表执行一次重建。常用做法是 ALTER TABLE ... ENGINE=InnoDB，它会按新的表空间设置重新创建表文件：

ALTER TABLE orders ENGINE=InnoDB;

这个操作会锁表并重建数据，大表执行时间可能很长，务必在业务低峰期做，并提前确认磁盘剩余空间足够（重建过程中新旧文件会短暂共存）。生产环境更稳妥的方案是用 pt-online-schema-change 或 gh-ost 这类在线改表工具，具体用法以官方文档和工具说明为准。迁移完成后，可以用 OPTIMIZE TABLE 或重建的方式把 ibdata1 回收，但共享表空间里的 undo 部分无法单独收缩，彻底回收通常需要导出数据、删除 ibdata1 后重新初始化，风险较高，不建议新手贸然操作。

OPTIMIZE TABLE 的适用边界

对于独立表空间的 InnoDB 表，OPTIMIZE TABLE 的实际动作是重建表并重建索引，等于把数据重新写一遍，因此能真正把 .ibd 文件缩小，把 data_free 降下来。它适合这几类情况：表经历过大量 DELETE、有频繁更新导致页分裂、或者刚做完大批量数据归档。

-- 单表整理，会锁表，建议低峰执行
OPTIMIZE TABLE orders;

-- 查看整理前后对比
SELECT table_name,
       ROUND(data_length/1024/1024, 2) AS data_mb,
       ROUND(data_free/1024/1024, 2) AS free_mb
FROM information_schema.tables
WHERE table_schema = 'shop' AND table_name = 'orders';

但它不是万能的，以下几种情况要谨慎：

一是表本身就不大、碎片很少时，整理收益有限，反而消耗 IO 和主从延迟。二是大表在业务高峰期不要做，InnoDB 的 OPTIMIZE 会持有表锁，期间写入会被阻塞。三是共享表空间里的表，OPTIMIZE 不会让 ibdata1 变小，因为文件只增不减。四是主从架构下要评估复制延迟，最好先在从库验证耗时。

另外，如果只是想回收磁盘又不想长时间锁表，可以考虑按主键范围分批归档老数据，再配合分区表把历史数据放到独立分区，需要时直接 DROP PARTITION，这种方式对线上影响更小，但需要提前规划表结构。

小结与下一步

处理 ibdata1 膨胀，核心是先判断数据到底存在哪里：开了独立表空间的表，空间在各自的 .ibd 里，用 OPTIMIZE TABLE 或重建可以回收；共享表空间和 undo 部分则受限于文件只增不减的机制，能做的就是尽早把 innodb_file_per_table 设为 ON，让新表走独立表空间。日常运维建议定期查一次 information_schema.tables 的 data_free，把明显偏大的表挑出来，在低峰期做整理，而不是等磁盘写满才手忙脚乱。涉及删除 ibdata1、重建实例这类高风险操作，一定先做完整备份并在测试环境演练，具体步骤以你所使用 MySQL 版本的官方文档为准。

继续阅读