本文详解MySQL索引碎片检测的3种核心方法，提供innodb_index_stats实操案例和OPTIMIZE TABLE替代方案，分享索引重建的黄金时间窗口判断技巧，并给出避免碎片复现的配置参数组合。
数据库查询变慢是不是索引碎片导致？
当发现SQL执行时间突然增加20%以上，特别是范围查询和全表扫描操作变慢时，80%的DBA会首先怀疑索引碎片问题。通过SHOW TABLE STATUS查看Data_free字段，当碎片空间超过表大小的30%就需要处理。某电商平台案例显示，订单表索引碎片率达42%时，用户查询延迟从200ms飙升到1.8秒。
检测三板斧：
1. 执行`SELECT FROM sys.schema_index_statistics WHERE table_schema=’your_db’`
2. 查看`INFORMATION_SCHEMA.INNODB_INDEX_STATS`的`pages_leaf%`指标
3. 使用pt-index-usage工具分析索引使用效率
在线业务如何安全整理索引碎片？
对于24小时运行的业务系统，直接使用OPTIMIZE TABLE会导致表锁。推荐采用分阶段操作：先用`ALTER TABLE … ENGINE=INNODB`重建表结构，再通过`ANALYZE TABLE`更新统计信息。某金融系统采用凌晨窗口期分片处理，每次处理500万数据，使碎片率从37%降至5%，IOPS下降40%。
- 热优化方案：设置innodb_optimize_fulltext_only=ON减少全文本索引影响
- 监控指标：重点关注read_next和read_prev的比值变化
索引重建后性能反而下降怎么办？
这种情况通常发生在错误的碎片判断场景。通过index_condition_pushdown状态变量可以验证索引实际使用效果。某社交平台案例显示，盲目重建消息表索引导致查询计划错误，通过调整optimizer_switch参数恢复性能。建议每次优化前保存`SHOW INDEX`结果用于对比。
// 优化前快照
SELECT INDEX_NAME, SEQ_IN_INDEX, CARDINALITY
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_NAME = 'user_log';MySQL索引维护FAQ
Q：碎片整理需要多久做一次？
建议结合业务波动周期，促销类系统每周检测，ERP系统每月检查。当数据修改量达到表体积的15%时触发整理。
Q：MyISAM和InnoDB处理方式有何不同？
MyISAM支持REPAIR TABLE，而InnoDB需通过ALTER重建。注意innodb_file_per_table必须开启才能有效回收空间。
Q：云数据库怎么处理碎片问题？
阿里云RDS推荐使用DMS的智能优化模块，AWS Aurora会自动处理碎片，腾讯云可通过定时存储过程实现无损优化。
