碎片率=(file_size-allocated_size)/file_size*100%，需过滤系统表空间、确保file_size>0且为独立表空间，值超30%才需关注，但应结合读写模式判断是否真正需要optimize table。
怎么从 INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES 算出表空间碎片率
它本身不直接存“碎片率”，得靠 FILE_SIZE 和 ALLOCATED_SIZE 两个字段自己算。MySQL 5.7+ 才有这个视图，且只对 InnoDB 表空间有效（比如独立表空间 .ibd 文件）。
公式就是：(FILE_SIZE - ALLOCATED_SIZE) / FILE_SIZE * 100，结果是百分比，值越大说明空洞越多。
-
FILE_SIZE：文件系统里该.ibd文件的实际大小（字节），含所有已分配和未分配页 -
ALLOCATED_SIZE：InnoDB 认为自己“已分配”用于存储数据/索引的字节数（按 extent 对齐，通常 1MB） - 注意：如果表刚建完没插入数据，
ALLOCATED_SIZE可能是 0，此时除零会报错，查的时候得加WHERE FILE_SIZE > 0
INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES 查出来的 ALLOCATED_SIZE 为什么比磁盘文件小
因为 ALLOCATED_SIZE 是 InnoDB 内部管理的“逻辑分配量”，不含文件头、undo 页、预留的 free space（比如每 64 个 extent 预留一个）；而 FILE_SIZE 是操作系统看到的完整文件大小。
- 常见现象：
ls -l看到的.ibd大小 = 128MB，但ALLOCATED_SIZE是 127MB —— 这 1MB 就是 InnoDB 的元数据开销 - 不是 bug，是设计如此：InnoDB 不把整个文件都当成“可用数据区”来用
- 所以碎片率计算时，分母必须用
FILE_SIZE，不能用ALLOCATED_SIZE，否则会高估碎片
查碎片率时容易漏掉的三个条件
直接 SELECT 全表会混入系统表空间（如 innodb_system）、临时表空间（innodb_temporary），它们的 ALLOCATED_SIZE 没意义，还可能为 NULL。
- 过滤掉非用户表空间：
WHERE NAME NOT LIKE 'mysql/%' AND NAME NOT LIKE 'sys/%' AND NAME NOT LIKE 'information_schema/%' - 排除共享表空间：
AND FILE_FORMAT = 'Barracuda'或更稳妥地AND ROW_FORMAT IS NOT NULL（共享表空间的ROW_FORMAT为 NULL） - 确保只查独立表空间：
AND NAME NOT LIKE '%/%'不够准，建议结合ENGINE = 'InnoDB'和TABLE_SCHEMA关联INFORMATION_SCHEMA.TABLES来定位真实业务表
碎片率高了要不要 OPTIMIZE TABLE
不一定。碎片率 > 30% 才值得警惕，但更要结合实际读写模式判断：
- 如果表以追加写为主（如日志表），碎片不影响性能，
OPTIMIZE TABLE反而会锁表、产生大量 I/O - 如果频繁
UPDATE大字段或DELETE后没VACUUM（InnoDB 没这命令），碎片可能影响范围扫描速度 -
OPTIMIZE TABLE在 MySQL 5.7+ 实际是重建表（ALTER TABLE ... FORCE），会触发 fulltext rebuild、触发器重装等副作用，线上执行前务必在从库验证
真正要盯的是那些 DATA_LENGTH 明显小于 FILE_SIZE 且 QPS 高的热点表 —— 碎片只是表象，背后往往是不合理的大字段更新或长事务未提交。
