MySQL表碎片与 OPTIMIZE TABLE：空间回收的代价与边界

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

有回清理历史数据，一张大表删掉了一大半。删完我去看磁盘，几乎没动。我以为删错了，又核对了一遍行数，确实少了。数据没了，空间却还占着。我第一反应是跑 OPTIMIZE TABLE，把空间收回来。结果那条命令跑了很久，磁盘更紧张了，业务也开始报慢查询。后来才分清楚，删数据和回收空间，中间隔着一道重建的成本。

删了数据，空间去哪了

InnoDB 删一行，不是马上把它从磁盘上抹掉。它把对应的页标记成可复用，放进表空间的空闲列表。这些页还能被新数据用上。DELETE 之后继续写入，空间是能复用的。可它们不会自动还给操作系统。你看到磁盘没降，是正常的。

碎片也不全是删出来的。主键随机插入、变长字段更新，同样会留空洞。页装满了再插，InnoDB 会做页分裂，把一页拆成两页。行变长放不下，就迁到另一页，原位置留个指针。

空隙攒多了，同样的行数要读更多页。表占的空间变大，扫表的 IO 也跟着涨。还有更隐蔽的一层。页里空着一半，一页能装的有效行就少。buffer pool 缓存的数据跟着变少，命中率会往下掉。空间的问题，最后会变成内存的问题。不过说到底，这些空隙都会算进同一个数。information_schema.tables 里的 DATA_FREE 就是这块空间。

sql 复制代码

SELECT table_name,
       ROUND(data_length/1024/1024, 1)  AS data_mb,
       ROUND(index_length/1024/1024, 1) AS index_mb,
       ROUND(data_free/1024/1024, 1)    AS free_mb
FROM information_schema.tables
WHERE table_schema = 'app_db'
ORDER BY data_free DESC;

free_mb 大，说明表里空着。但空着不等于能还回去，得先看它是不是在独立表空间里。顺便说一句，TRUNCATE 和 DROP 会把整张表的空间还给操作系统，DELETE 不会。所以要清空整表，别用 DELETE 一行一行删。

先问一句：你缺的是空间，还是性能

很多人跑到这一步就直接 OPTIMIZE。先停一下，问自己缺什么。缺空间，才谈回收。缺性能，碎片多半不是主因。查询慢先去查执行计划、索引、统计信息，别拿 OPTIMIZE 当万能药。碎片带来的收益，通常远小于它花的代价。

缺空间也分两种。磁盘还宽裕，那不用管，这些页迟早被新数据复用。磁盘真的紧，才需要缩一次。这里有个前提。只有 innodb_file_per_table=ON，每张表才有自己的 .ibd 文件，缩表才有意义。要是还开着共享表空间，空间都在 ibdata1 里，OPTIMIZE 单表也缩不回操作系统。

sql 复制代码

SHOW VARIABLES LIKE 'innodb_file_per_table';

怎么量碎片，别被 DATA_FREE 骗

DATA_FREE 能看个大概，但它有个坑。它统计的是表空间里的空闲页，不完全等于碎片。有些空闲页是预留的，有些才是碎片，混在一起。所以别只盯一个数，先把比例算出来。如果表是分区表，information_schema.tables里的DATA_FREE是估算值，更准确的方式是查INFORMATION_SCHEMA.PARTITIONS，把各分区的DATA_FREE加起来。

sql 复制代码

SELECT table_name,
       ROUND(data_free / (data_length + index_length + data_free) * 100, 1) AS frag_pct
FROM information_schema.tables
WHERE table_schema = 'app_db' AND data_free > 0
ORDER BY frag_pct DESC;

一般超过百分之二三十，才值得往下谈回收。可比例只是一个数，还得看两样：

删掉了多少行，表实际行数降了多少
查询有没有真的变慢

只有「删了很多、空间吃紧、查询也受影响」同时成立，OPTIMIZE 才值得做。单独看 DATA_FREE 大就动手，多数时候是白忙。

OPTIMIZE 到底做了什么

它本质是一次表重建。8.0 里 InnoDB 的 OPTIMIZE 会映射成 ALTER TABLE ... FORCE，把表重新写一遍，把空洞挤掉。

sql 复制代码

OPTIMIZE TABLE t_order;
-- 等价于重建表：ALTER TABLE t_order FORCE;

默认走在线 DDL，允许并发写入。但这不代表没代价。第一，开始和结束要拿元数据锁。正好有长事务或慢查询在表上，它就排队等，后面的 DML 也跟着堵。第二，要额外空间。重建时得写一份新的表文件，大小接近原表。磁盘本来就紧，这一下可能直接写满。这也解释了我那次磁盘为什么更紧张。

第三，很吃 IO，也会产生大量 redo 和 binlog。大表重建，主从延迟跟着起来。第四，它是一次性的。表以后继续删、继续写，还会再产生空洞。别把它当日常保养。

还有个附带效果。重建会把二级索引一起重写，统计信息也重新采样。有些表重建后查询变快，不是碎片少了，是统计信息终于对了。这个收益换个方式也能拿到。别把功劳全算在碎片上，更别为了它去动一张大表。

该不该做，看这张表

场景	建议
表不大、磁盘紧、低峰窗口够	可以 OPTIMIZE
大表、写入热点、窗口不够	别直接做，走在线工具或分区
碎片占比不高	不值得，收益有限
查询慢但碎片不是主因	先查索引和执行计划
共享表空间（file_per_table=OFF）	OPTIMIZE 单表缩不回去
刚删完、后面还有大量写入	先别做，空页很快被复用
碎片高但表只有几十 MB	收益太小，不值得开窗口

大表要重建，我更倾向两种做法。一种是分区滑动。按时间分区的表，历史分区直接 DROP PARTITION，空间立刻回来，不用重建整张表。前提是表和查询都按分区键走。

另一种是在线重建工具。gh-ost 或 pt-online-schema-change，边搬数据边限速，能控制对主库和主从的影响。

bash 复制代码

# pt-osc 在线重建，带限速
pt-online-schema-change \
  --alter "ENGINE=InnoDB" \
  --max-load Threads_running=30 \
  --critical-load Threads_running=60 \
  --sleep 0.5 \
  D=app_db,t=t_order

--max-load 和 --critical-load 是两道刹车，压力高了自动停。比裸跑 OPTIMIZE 稳得多。两个工具的路子不一样，选之前先看清楚。

工具	怎么搬增量	代价
pt-osc	建触发器，把增量同步进影子表	每行写入多一层触发器开销，外键场景受限
gh-ost	订阅 binlog，把增量回放进影子表	依赖 ROW 格式，磁盘要留两份表的余量

两个都要额外磁盘，也都绕不开 cut-over 那一刻的短暂锁。工具能限速，省不掉空间。空间够不够，先算再决定。下面这条查出重建大致要多大，再拿 df -h 对一下余量。留不到原表的一点二倍，就别在这台机器上动手。

sql 复制代码

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS rebuild_mb
FROM information_schema.tables
WHERE table_schema = 'app_db' AND table_name = 't_order';

真要跑，盯住这几点

重建一开始，先确认别被元数据锁堵住。有长事务持着这张表的 MDL，OPTIMIZE 就得一直等，后面的 DML 跟着排队。

sql 复制代码

SELECT waiting_pid, waiting_table, blocking_pid, sql_kill_blocking_query
FROM sys.schema_table_lock_waits;

waiting 里是 ALTER TABLE，blocking 是一条长事务，那就别干等。先把那条事务处理掉。跑起来之后，盯三样：主从延迟、Threads_running、剩余磁盘。哪个不对就停。要停可以 KILL。但在线 DDL 有回滚，回滚本身也要时间，别以为停一下就立刻干净。

缺的是空间，才谈回收

OPTIMIZE 不是日常保养，是一次手术。手术要有指征，要备血，要挑时间。你缺的是磁盘，才谈回收。缺的是速度，先查别处。把两件事混在一起，就容易在不该动刀的时候动刀。结果业务也跟着慢。

还有一种情况容易被忽略。表定期清，机器却一直没扩容。每次靠 OPTIMIZE 硬挤，挤出几十 G，过两个月又满。这是在拿手术替代体检。空间规划得回到容量和分区设计上。一张表一张表地救，救不过来。

避坑清单

删了数据磁盘不降是常态，InnoDB 不会自动把页还给操作系统。别一看没降就慌，先看磁盘还够不够。

OPTIMIZE 要额外空间、要拿 MDL、吃 IO。大表别直接跑，低峰、留足空间，或用在线工具限速。

最后一条是我自己踩的。我有回磁盘紧，直接对大表跑了 OPTIMIZE，没算临时空间。跑到一半磁盘更满了，业务查询也跟着慢。后来才知道，重建要一份接近原表大小的空间。现在我做之前，先看剩余空间够不够原表的一点二倍。不够就先扩容，或者换方案。

写在最后

删数据容易，回收空间要算账。重建的成本、锁的等待、IO 的冲击，还有一份额外空间，全在账上。这笔账也让我重新认识了「删除」。在数据库里，大多数删除只是逻辑上的。行没了，空间还在，空洞替你记着发生过什么。

想让它真的回来，得有人挑时间、留余量、承担一次完整的重建。这件事没有捷径。代价不会消失，只会换个地方付。

所以碎片这道题，难在判断，不在命令。你缺的是磁盘还是速度，现在该动还是该等，都得自己拿主意。磁盘会满，业务会忙。能在这两件事之间做对一次选择，比会敲十条命令值钱。

你们的表碎片是定期清，还是磁盘告警了才清？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋