表碎片率超20%且explain显示rows远大于filtered*rows或频繁using temporary/filesort才需优化；否则可能无效甚至更慢。
直接说结论：表碎片率超过 20% 且伴随 Using temporary; Using filesort 或 rows 远大于 filtered * rows，才值得动；否则优化可能白忙，甚至让查询更慢。
怎么确认是不是真碎片拖慢了查询
别只看磁盘满了或 Data_free 高——那只是表象。真正要盯的是它是否影响了实际扫描效率：
-
Data_free / (Data_length + Index_length)> 0.2（即碎片率超 20%）是硬门槛，低于这个值基本不用理 - 查
EXPLAIN结果里rows字段是否异常大，同时filtered很低（比如 10%），说明 B+ 树深度失衡、页内空洞导致扫描行数虚高 - 慢查询日志中频繁出现
Using temporary; Using filesort，且没走覆盖索引，大概率是碎片让排序/分组的临时表变大、缓存命中率下降 - 用
SELECT (data_length + index_length) / table_rows AS avg_row_size算出平均行大小，如果比业务字段总和大 2 倍以上（比如字段加起来 200 字节，却算出 600 字节），说明页内填充率极差
执行 OPTIMIZE TABLE 前必须检查的三件事
这个命令在 InnoDB 上不是“点一下就完事”，缺一不可，否则会卡住、失败或白跑：
- 磁盘剩余空间 ≥
Data_length + Index_length（从SHOW TABLE STATUS LIKE 't'查），不是“差不多”，是必须够——重建过程会先写新.ibd文件，再原子替换 - 确认无长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started ，有结果就别动，等它结束 - 检查
innodb_file_per_table必须为ON；若为OFF，所有表共用ibdata1，OPTIMIZE TABLE根本无法把空间还给操作系统，只会内部复用
为什么 ALTER TABLE t ENGINE=InnoDB 比 OPTIMIZE TABLE 更可控
语义明确、行为稳定，尤其适合生产环境的大表：
- 效果完全等同于
OPTIMIZE TABLE（InnoDB 下本质就是隐式ALTER TABLE ... ENGINE=InnoDB），但不会触发自动ANALYZE TABLE，避免统计信息突变导致执行计划抖动 - MySQL 5.6+ 支持
ALGORITHM=INPLACE LOCK=NONE，可显式控制锁级别：ALTER TABLE t ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE - 对超大表（>10GB），建议配合调大会话级排序缓冲：
SET SESSION sort_buffer_size = 268435456（256MB），加速重建阶段 - 不重置
AUTO_INCREMENT值，也不影响外键约束或触发器定义，比逻辑导出导入更轻量
碎片清理后查询还是慢？重点看这三点
优化不是万能解药，很多“无效”其实是误判或后续动作没跟上：
- 刚优化完首条查询必然慢——
innodb_buffer_pool_size不够大时，数据页全冷，得等缓存热起来；别拿第一条响应时间当基准 -
OPTIMIZE TABLE会重置统计信息，原本走idx_a_b的查询可能突然改走全表扫描；优化后应手动ANALYZE TABLE t更新统计，再观察执行计划 - 如果慢查询集中在某个高频更新字段（如
status、updated_at）上的索引，它本身就在持续制造碎片；考虑删掉该单列索引，或把它挪到复合索引后缀位（如idx_created_at_status→idx_created_at_status）
最易被忽略的一点：碎片从来不是孤立问题。它常和缓冲池配置、主键设计、批量操作习惯捆绑出现。一次 ALTER TABLE 能拍平当前结构，但若主键仍是随机 UUID、又天天单行 UPDATE，几周后又回到原点。
