DELETE慢的核心原因是隐式操作（索引维护、外键检查、触发器、日志写入）及低效WHERE导致全表扫描；优化需确保索引命中、分批删除、减少隐式开销，并考虑TRUNCATE或分区裁剪等替代方案。
DELETE 慢，核心原因通常不是语句本身，而是它背后触发的隐式操作：索引维护、外键检查、触发器执行、事务日志写入，以及最常被忽略的——全表扫描或低效的 WHERE 条件导致大量行被锁定和处理。优化 DELETE 性能，关键在减少“实际要处理的数据量”和“每次处理的开销”。
检查 WHERE 条件是否走索引
没有有效索引的 DELETE 很容易退化为全表扫描，尤其在大表上，I/O 和锁等待会急剧上升。
- 用 EXPLAIN（MySQL）或 EXPLAIN (ANALYZE)（PostgreSQL）看执行计划，确认 WHERE 字段是否命中索引；
- 如果条件含函数（如
WHERE DATE(create_time) = '2024-01-01'）或隐式类型转换，索引大概率失效，应改写为范围查询（如create_time >= '2024-01-01' AND create_time < '2024-01-02'）； - 复合索引需满足最左前缀原则，确保 DELETE 中的过滤字段是索引的前导列。
避免一次性删太多行
单次删除百万级数据会引发长事务、日志暴涨、锁表时间过长，甚至 OOM 或主从延迟。
- 拆成小批量删除，例如每次删 1000–5000 行，用主键/自增 ID 分页推进：
DELETE FROM orders WHERE id BETWEEN 100001 AND 105000; - 配合 WHERE + LIMIT（MySQL）或 USING LIMIT/OFFSET（PostgreSQL，注意 OFFSET 深度大时效率下降）；
- 加 SLEEP(0.1) 或应用层延时，缓解对系统资源的冲击。
关注隐式开销：外键、触发器与事务隔离
这些功能虽保障一致性，但显著拖慢 DELETE 速度，尤其在外键引用多或触发器逻辑复杂时。
- 临时禁用外键检查（仅限维护窗口且确认安全）：
SET FOREIGN_KEY_CHECKS = 0;（MySQL），删完再开启； - 检查是否有 BEFORE/AFTER DELETE 触发器，评估其逻辑是否必要；可考虑先禁用，批量删完再补业务逻辑；
- 高并发场景下，避免在 READ-COMMITTED 或 REPEATABLE-READ 下执行大删，可能因间隙锁（Gap Lock）扩大锁定范围；可考虑降级到 READ-UNCOMMITTED（仅分析用）或分批+显式事务控制。
替代方案：TRUNCATE 或 DROP + RECREATE
如果目标是清空整表或按分区删除，DELETE 是最重的方式。
- TRUNCATE TABLE 快得多：不走事务、不记录逐行日志、自动重置自增 ID（但无法回滚，且不能带 WHERE）；
- 按时间分区的表，优先用 DROP PARTITION（MySQL）或 DETACH PARTITION（PostgreSQL），毫秒级完成；
- 若需保留部分数据，可新建表插入目标数据，再原子切换（
RENAME TABLE），比反向 DELETE 更高效。
不复杂但容易忽略。删之前先看执行计划，删之中控制节奏，删之后留意日志和锁状态。真正影响 DELETE 速度的，往往不是 SQL 写法，而是你没意识到它正在为每一行做多少事。
