频繁delete不会使索引失效，但导致b+树页内空洞增多、页间链断裂、purge滞后及统计失真，引发i/o增加、缓冲池命中率下降和执行计划误判。
频繁 DELETE 不会让索引“失效”，但会让 B+ 树页内产生大量空洞、页间物理顺序断裂，最终导致查询时读更多页、缓冲池命中率下降、优化器统计失真——这才是变慢的根因。
DELETE 只打标记，不回收空间
InnoDB 的 DELETE 实际只是把行标记为“已删除”（delflag=1），并不立即释放页内空间。这些空洞页仍保留在 B+ 树结构中，后续 INSERT 能复用它们，但前提是新数据能“恰好填进去”。现实中，随机主键、变长字段更新、非顺序写入都会让空洞长期滞留。
- 页内空洞 →
avg_page_space_used_in_percent下降 → 单页有效数据变少 → 扫描同样行数需读更多页 - 页链断裂 → 范围查询（
WHERE id BETWEEN 100 AND 200）需跳转更多物理位置 → 随机 I/O 增多 - Purge 线程清理滞后 → 空洞堆积时间越长，后续重建代价越高
统计信息失真会误导执行计划
优化器依赖 Cardinality 和 n_diff_pfx01 做成本估算。大量删除后，这些值不再反映真实分布，但 ANALYZE TABLE 默认采样可能无法修正：
-
SHOW INDEX FROM t中Cardinality接近 0 或恒为 1，而字段明明有唯一约束 → 统计严重过期 -
SELECT * FROM information_schema.INNODB_INDEX_STATS WHERE table_name = 't'显示n_leaf_pages异常高、n_diff_pfx01远低于实际唯一值 → 索引逻辑膨胀 - 执行
ANALYZE TABLE t后无变化？说明采样不足或数据倾斜（如某列 95% 是NULL），需强制重建
碎片不是“看不见的空间浪费”，而是 I/O 效率崩塌
碎片影响不体现在磁盘占用上（DATA_FREE 可能为 0），而直接作用于每次查询的物理读路径：
- 机械盘场景：一次范围扫描本该顺序读 10 页，因碎片变成 30 次随机寻道 → 延迟翻 3 倍
- SSD 场景：虽无寻道开销，但页利用率低 → 缓冲池加载效率下降 →
Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads比值持续走低 - 即使
EXPLAIN显示 “rows=1000”，实际磁盘 I/O 可能是原来的 2–4 倍
真正难处理的不是“怎么修”，而是“删的时候没控制节奏”——百万级 DELETE FROM t WHERE status='old' 一跑完，空洞就已固化；等你发现变慢再 OPTIMIZE TABLE，不仅耗双倍磁盘空间，还锁表、阻塞写入。最隐蔽的坑在于：问题在删那一刻就埋下了，但症状要等几小时甚至几天后才浮现。
