DATA_FREE是InnoDB表中已分配但未使用的空间字节数，反映表空间碎片；其值显著大于0且长期不降（如超总大小20%）是碎片强信号，但为0不代表无碎片，因页内空洞或共享表空间等情况仍可能存在碎片。
data_free 是什么，为什么能反映碎片
DATA_FREE 是 INFORMATION_SCHEMA.TABLES 中的一个字段，表示表在存储引擎层（主要是 InnoDB）中**已分配但未使用的空间字节数**。它不是“空闲空间”的精确度量，而是 InnoDB 为下一次扩展预留的、尚未被实际数据或索引填充的页空间。当频繁执行 DELETE 或 UPDATE（尤其是大字段变更）后，InnoDB 不会立即归还磁盘空间给操作系统，而是保留在表空间内供后续插入复用——这部分就体现为 DATA_FREE 增长。
所以：DATA_FREE 显著大于 0（比如超过表总大小的 20%），且长期不下降，是表存在明显碎片的强信号；但不能单看绝对值，需结合 DATA_LENGTH 和 INDEX_LENGTH 综合判断。
如何查出高碎片表（带阈值过滤）
直接查 INFORMATION_SCHEMA.TABLES 并计算碎片率更可靠。以下语句按碎片率降序列出可能需要优化的 InnoDB 表：
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, ROUND(DATA_FREE / (DATA_LENGTH + INDEX_LENGTH + 1), 2) AS frag_ratio FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'InnoDB' AND DATA_LENGTH > 0 AND (DATA_FREE / (DATA_LENGTH + INDEX_LENGTH)) > 0.15 ORDER BY frag_ratio DESC;
说明：
-
DATA_LENGTH + INDEX_LENGTH + 1的+1是防止除零错误，非真实加法 -
> 0.15表示碎片率超 15%，可根据业务容忍度调整（如 OLTP 系统建议 10%，归档表可放宽） - 注意：MyISAM 表的
DATA_FREE含义不同（仅表示删除后留下的空洞），不适用于此逻辑
data_free 为 0 一定没碎片？不一定
这是常见误判点。以下情况会导致 DATA_FREE = 0 但表仍有碎片：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- InnoDB 已将所有预留空间填满（比如刚做完大批量 INSERT），此时
DATA_FREE归零，但旧 DELETE 留下的页内空洞仍存在（DATA_FREE不统计页内碎片） - 使用了
innodb_file_per_table = OFF，所有表共享系统表空间ibdata1，此时DATA_FREE反映的是整个系统表空间的空闲页，和单表无关 - 表刚被
OPTIMIZE TABLE或ALTER TABLE ... FORCE重建过，DATA_FREE被重置，但若后续有大量短生命周期行（如会话表），碎片会快速再生
真正检测页内碎片，得靠 SHOW TABLE STATUS 中的 Data_free（同名但来源不同）或解析 INFORMATION_SCHEMA.INNODB_METRICS 中的 buffer_pool_pages_misc 等指标，不过那已超出 DATA_FREE 的能力范围。
清理碎片时 data_free 会怎么变
执行 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 后，DATA_FREE 通常会先清零，然后缓慢回升——这是正常现象。
- 重建过程会创建新表空间，拷贝数据并紧凑排列，释放旧碎片，所以初始
DATA_FREE接近 0 - 但 InnoDB 会立刻为该表预分配若干空闲页（受
innodb_fill_factor控制，默认 90%，即预留 10% 空间），所以很快能看到几 MB 的DATA_FREE - 如果重建后
DATA_FREE迅速涨到几十 MB，说明写入压力大或innodb_fill_factor设得太低（如 50），反而浪费空间
别盯着 DATA_FREE 是否为 0 做判断，重点看重建前后 DATA_LENGTH 是否显著下降、查询响应是否变快——这才是碎片清理有效的证据。
