delete后表扫描仍慢，根本原因不是数据减少，而是索引空洞增多、统计信息过期导致优化器误判并放弃索引，进而引发全表扫描；需通过analyze table更新统计、optimize table或alter table engine=innodb重建索引以恢复性能。
DELETE 后表扫描仍慢，大概率不是数据少了，而是索引坏了
删掉几百万行后 SELECT 还是全表扫描、EXPLAIN 显示 type: ALL，这不是“删得不够”，而是删除操作本身加剧了索引失效和数据碎片。InnoDB 删除不物理释放页空间，只打标记，后续查询仍要遍历大量空洞页；同时频繁删除会让统计信息过期，优化器误判成本，主动放弃可用索引。
- 删完不
ANALYZE TABLE（MySQL）或VACUUM ANALYZE（PostgreSQL），优化器还在用旧的行数估算，可能选错执行路径 - 二级索引页产生大量空洞，B+Tree 深度没变但有效数据密度下降，
rows预估偏高，触发全表扫描倾向 - 如果删的是高选择性范围（如时间字段末尾），剩余数据集中在索引某一段，但 B+Tree 仍需从根节点开始搜索，I/O 并未减少
- 外键约束或触发器残留逻辑可能让优化器绕过索引，尤其在 MySQL 5.7+ 中对复杂外键场景的索引推导更保守
WHERE 条件列有索引，但 EXPLAIN 显示 key=NULL
建了索引却没走，常见于隐式行为破坏了索引可用性。数据库不会因为“你建了索引”就自动用它，而是严格按 WHERE 表达式的可索引性判断。
-
WHERE DATE(create_time) = '2024-01-01'→ 函数包裹导致索引失效，哪怕create_time有索引也白搭 -
WHERE status = 1但status是VARCHAR类型，传入数字会触发隐式转换，MySQL 放弃索引 - 联合索引
(a, b, c)，只写WHERE b = ? AND c = ?→ 不满足最左前缀，无法命中 -
WHERE col != 'x'或WHERE col NOT IN (...)→ 大多数引擎拒绝使用索引，直接全表扫描
删完数据，OPTIMIZE TABLE 也没用？
OPTIMIZE TABLE 在 MySQL 中本质是重建表，能整理碎片、更新统计信息，但它不是万能解药。对大表而言，它会锁表、阻塞写入，且在某些场景下效果有限。
- 如果表启用了
innodb_file_per_table=OFF，OPTIMIZE无法真正回收磁盘空间，只是整理内部页 - 删的是历史冷数据，但主键/聚簇索引分布稀疏（比如 ID 跳变严重），重建后 B+Tree 结构仍不紧凑
- 存在大量长事务未提交，
purge线程被阻塞，undo 日志堆积，导致OPTIMIZE无法清理已删除行的版本链 - MySQL 8.0+ 默认启用
innodb_defragment，但该功能对随机删除后的碎片整理效果弱于显式重建
为什么分批 DELETE 后，后续 SELECT 反而更慢？
这不是幻觉。分批删引发的连锁反应，会真实拖垮后续读性能：每删一批，都伴随索引更新、日志刷盘、缓冲池污染，而这些代价会持续影响接下来的查询。
- 每批
DELETE都写大量redo log和undo log，若innodb_log_file_size小，频繁 checkpoint 导致刷盘争抢，拖慢所有写+读 - 删除期间
buffer pool被大量空洞页和 undo 页面占据，有效缓存命中率下降，SELECT更多走磁盘 - 分批用
LIMIT但没加ORDER BY，每次扫描起始点不确定，可能反复读取同一组页，放大 I/O 压力 - 如果删除和查询共用同一连接或事务上下文，MVCC 版本链因 undo 未清理而持续增长，
SELECT判断可见性开销陡增
