不是索引“失效”，而是统计信息过期与b+树空洞堆积导致优化器误选执行计划；需查show index的cardinality及innodb_index_stats的n_diff_pfx01、n_leaf_pages，执行analyze table或重建索引修复。

不是索引“失效”了，而是统计信息过期 + B+ 树空洞堆积，让优化器选错了执行计划。

为什么删完数据查询变慢？本质是优化器“看走眼”了

DELETE 不会删掉索引结构，但会留下大量空洞页（empty pages），同时 InnoDB 的统计信息（如 Cardinality）仍基于旧采样，没自动更新。结果就是：EXPLAIN 显示 rows 高估几倍甚至几十倍，优化器误判成本，放弃本该走的索引，退化成全表扫描。

常见现象包括：

• 明明 WHERE status = 'done' 有索引，EXPLAIN 却显示 type: ALL
• key_len 突然变小，或 key 列为空
• 同一语句，删前毫秒级，删后秒级，且 ANALYZE TABLE 后立刻恢复

怎么确认是不是统计失真导致的？

别猜，直接查系统视图：

• 运行 SHOW INDEX FROM your_table，重点看 Cardinality 列 —— 如果远低于该列实际唯一值数量（比如字段有 10 万不同值，Cardinality 却是 1 或 100），基本就是统计过期
• 查 information_schema.INNODB_INDEX_STATS，对比 n_diff_pfx01（估算唯一值）和 n_leaf_pages（叶子页数）：若后者异常高、前者异常低，说明空洞多、分布碎
• 执行 ANALYZE TABLE your_table 后再查一遍，如果 Cardinality 无明显变化，说明默认采样率不够，需强制更新

重建索引 ≠ 万能解，得看场景选对方式

重建目标是清理空洞 + 刷新统计，但不同命令行为差异大：

• OPTIMIZE TABLE your_table：InnoDB 下等价于 ALTER TABLE ... FORCE + 更新统计；8.0+ 支持在线，但 DML 仍会被短暂阻塞；适合中小表（
• ALTER TABLE your_table ENGINE=InnoDB 或 FORCE：显式重建聚簇索引，重排物理顺序；需要约等于原表大小的额外磁盘空间
• DROP INDEX idx_name ON your_table; ADD INDEX idx_name (col);：只重建单个二级索引，不碰聚簇索引；适合某索引严重退化但主键结构尚可时；注意 DROP 瞬间该列就无法走索引

别在高峰期跑 OPTIMIZE 或 ALTER TABLE，尤其大表 —— 它们会触发全表拷贝和锁。

真正要控制的，是删除动作本身

频繁重建索引只是补救，源头问题在 DELETE 方式：

• 删 >30% 数据时，优先用建表替换：CREATE TABLE new_t AS SELECT * FROM old_t WHERE keep_condition; + RENAME，比 DELETE + OPTIMIZE 更快更稳
• 必须用 DELETE 时，严格按主键/时间范围分批：DELETE FROM t WHERE id BETWEEN 1000001 AND 1010000 LIMIT 10000，避免 LIMIT ... OFFSET 和无序扫描
• 删完立即 ANALYZE TABLE，别等第二天——统计滞后是查询变慢最常被忽略的临门一脚

空洞和统计偏差不会自己修复，也不会在你下次 SELECT 时悄悄更新。它就在那里，等着某条看似正常的查询突然卡住。