经常使用 MySQL 的话，会发现 MySQL 数据文件的磁盘空间一般会不停的增长，而且有时候删了数据或者插入一批数据的时候，磁盘空间有时候还会毫无变化。引发这个其妙现象的就是 MySQL 的表空间碎片。
表空间碎片指的是表空间中存在碎片，形象一点来比喻的话，就像是一张 A4 纸，“表空间碎片”就像是把这张 A4 纸撕碎，再重新拼起来，各个碎片之间都会有一些缝隙存在，这些缝隙就是“表空间碎片”。重新拼起来的碎片实际上会比完整的 A4 纸大上一圈，这也代表着表空间容易引发的问题：空间浪费。
对于背景中描述的现象，可以用一张图来进行解释：
图中的数字代表真实的数据行，圆角矩形代表一个表的表空间。从左往右，第一次操作是删除数据，由于 MySQL 在设计上是不会主动释放空间的，因此当表中的数据行被删除时，虽然数据被“删除”了，但是实际上这部分空间是没有释放的，依旧会被 Table A 占用，因此也就出现了这样子的情景：删除了日志表的很多数据，但是 MySQL 的磁盘空间并没有降低。
PS：这种不释放空间的设计多半和惰性删除有关，早期设计数据库时，使用的 IO 设备一般是机械盘，读写性能比 SSD 差很多，所以删除操作一般不会直接触发磁盘上的数据删除。
可以看到数据删除之后，原本连续的空间中出现了两个空白的区域，这种一般就叫做表空间空洞，空洞太多了就叫做表空间碎片化（对应的是表空间连续）。这部分的空间虽然不会释放，但是会被标记为可重复利用，参考最右边的表空间示意图（第三个圆角矩形），当新插入数据的时候新数据会重新写入到表空间空洞中，这也代表着：在大规模删除过数据的表上，写入数据时，表空间可能不会明显增长或者不会增长。
实际上产生表空间空洞的操作并不只有 delete，update 也会引起这个问题，比如在 varchar 这种变长的字符型列中修改数据，改短一些的时候就会出现非常小的空洞，改长的话就有可能会因为空间不足导致把数据行的一些数据迁移到其他地方去。
MySQL 的系统表记录了表空间的使用情况，可以用如下查询检查：
SELECT CONCAT(table_schema,'.',table_name) AS 'table_name',
table_rows AS 'Number of Rows',
CONCAT(ROUND(data_length/(1024*1024),2),' M') AS 'data_size',
CONCAT(ROUND(index_length/(1024*1024),2),' M') AS 'index_size' ,
CONCAT(ROUND(data_free/(1024*1024),2),' M') AS'data_free',
CONCAT(ROUND(data_free/data_length,2),' %') AS 'data_free_pct',
ENGINE as 'engine'
FROM information_schema.TABLES
WHERE table_schema = 'tablename'
ORDER by data_free desc;
data_free 指表空间碎片的总空间大小，data_free_pct 指这个表的碎片百分比，效果如下：
mysql> SELECT CONCAT(table_schema,'.',table_name) AS 'table_name',
-> table_rows AS 'Number of Rows',
-> CONCAT(ROUND(data_length/(1024*1024),2),' M') AS 'data_size',
-> CONCAT(ROUND(index_length/(1024*1024),2),' M') AS 'index_size' ,
-> CONCAT(ROUND(data_free/(1024*1024),2),' M') AS'data_free',
-> CONCAT(ROUND(data_free/data_length,2),' %') AS 'data_free_pct',
-> ENGINE as 'engine'
-> FROM information_schema.TABLES
-> WHERE table_schema = 'sbtest'
-> ORDER by data_free desc;
+----------------+----------------+-----------+------------+-----------+---------------+--------+
| table_name | Number of Rows | data_size | index_size | data_free | data_free_pct | engine |
+----------------+----------------+-----------+------------+-----------+---------------+--------+
| sbtest.sbtest5 | 0 | 0.02 M | 0.00 M | 44.00 M | 2816.00 % | InnoDB |
| sbtest.sbtest4 | 986400 | 214.70 M | 15.52 M | 4.00 M | 0.02 % | InnoDB |
| sbtest.sbtest3 | 986400 | 214.70 M | 15.52 M | 4.00 M | 0.02 % | InnoDB |
| sbtest.sbtest2 | 986400 | 214.70 M | 15.52 M | 4.00 M | 0.02 % | InnoDB |
| sbtest.sbtest1 | 987400 | 199.70 M | 15.52 M | 4.00 M | 0.02 % | InnoDB |
+----------------+----------------+-----------+------------+-----------+---------------+--------+
5 rows in set (0.00 sec)
第一行数据是测试用的数据，表中的所有数据都被删掉了，因此计算出来的 data_free_pct 超过了 100%。
目前，能够回收表空间的办法仅有一个，就是重建表，手段包括但不限于 optimize，alter table 等。alter table 的有些操作只能靠 rebuild 表来完成，所以有时候对大表进行一些维护操作之后，也会看到磁盘空间使用率下降，这就是回收了表空间碎片腾出来的那一部分空间。
从一般经验来看，表空间碎片的回收操作不建议经常执行，每个月一次就足够了，因为 rebuild 表对服务器的资源影响会比较大，且会影响这个表的写入操作。碎片率（data_free_pct）低于 20% 的时候也不用特别在意，除非磁盘空间非常紧张，且日志基本被清空。
对一些日志表，或者是有区域性特征的表，建议使用 MySQL 的分区表来管理，需要清理一批数据的时候，可以用 partition truncate 的方式进行清理，磁盘空间也能直接释放掉。
