delete后查询变慢的根本原因是空间未回收导致物理存储结构退化，而非数据残留；逻辑删除产生“空洞”，全表或范围扫描仍需遍历含空洞的数据页，增加io开销。
DELETE 后查询变慢的根本原因不是“数据还在”，而是“空间没回收”
MySQL 的 DELETE 语句默认只做逻辑删除：它把对应行标记为“已删除”，但不立即释放磁盘空间，也不整理页内碎片。后续 SELECT 查询仍要扫描这些“空洞”所在的页，尤其是当 WHERE 条件无法走索引时，InnoDB 会执行范围扫描或全表扫描，自然拖慢响应——这不是数据量大导致的慢，是物理存储结构退化导致的慢。
OPTIMIZE TABLE 不是万能药，它在高并发场景下反而危险
执行 OPTIMIZE TABLE 会重建整张表（相当于 ALTER TABLE ... FORCE），期间对表加 排他锁，所有读写请求都会阻塞。在生产环境，尤其主从架构中，还可能引发主从延迟飙升、从库复制中断等问题。更关键的是：它只对 InnoDB 和 MyISAM 有效，而 MyISAM 已基本淘汰；对 InnoDB 来说，它本质是触发一次隐式 ALTER TABLE，开销大、耗时长、风险高。
- 它不能在线执行（除非使用
ALGORITHM=INPLACE且满足严格条件） - 它不会清理 undo log 或 purge 队列，那些“被删但未真正回收”的记录依然影响 MVCC 快照链长度
- 它对分区表无效——你得对每个分区单独
OPTIMIZE，操作成本翻倍
真正有效的清理方式是“分区裁剪”或“TRUNCATE PARTITION”
如果你的数据天然带时间维度（如日志、订单、埋点），分区表才是应对高频删除的正解。例如按月分区后，ALTER TABLE logs DROP PARTITION p202401 是元数据操作，秒级完成，不产生 undo log，不锁全表，不触发 purge 压力，且磁盘空间立即归还给文件系统。
- 分区键必须是
WHERE删除条件的一部分，否则 MySQL 无法自动 prunning -
DROP PARTITION不支持二级分区下的子分区直接删除，需先合并再删 - 注意：分区表的
PRIMARY KEY必须包含分区字段，否则建表失败
为什么分批 DELETE + LIMIT 之后查询还是慢？
很多人用 DELETE FROM t WHERE ts 循环删，以为能缓解压力。但问题在于：如果 <code>ts 字段没有索引，每次 LIMIT 都会触发全表扫描找前 1000 行；即使有索引，InnoDB 在删除过程中仍要维护二级索引、更新 undo log、触发 purge 线程异步清理——这些后台动作持续占用 I/O 和 CPU，间接拖慢并发查询。
- 务必确认
WHERE条件字段有高效索引，且选择性足够（避免在低基数字段如status上建单列索引） - 删除后立刻执行
ANALYZE TABLE，刷新统计信息，防止优化器误判索引失效而走全表扫描 - 不要依赖
SLEEP()缓解负载——它只是让应用层“等”，不减少数据库真实压力
