MySQL 中 DELETE 慢的主因是底层执行机制与数据组织，优化需减少锁竞争、降低 I /O、避免全表扫描，并合理使用索引、分批删除及替代方案。
MySQL 中 DELETE 语句慢，通常不是 SQL 写法本身的问题，而是底层执行机制和数据组织方式导致的。优化核心在于减少锁竞争、降低 I / O 开销、避免全表扫描，并合理利用索引与事务控制。
确保 WHERE 条件走索引
没有索引的 DELETE 会触发全表扫描，不仅慢，还会长时间持有行锁甚至表锁（尤其在非 InnoDB 或低版本中）。务必检查执行计划：
- 用EXPLAIN DELETE …（MySQL 8.0.18+ 支持）或改写为 SELECT 验证索引使用情况
- WHERE 字段必须是复合索引的最左前缀；若含函数（如 DATE(create_time)）或 隐式类型转换，索引可能失效
- 范围条件（如BETWEEN、>）后无法使用索引的后续列，设计复合索引时要把等值条件放前面
分批删除 大数据 量记录
一次性删百万级数据会引发长事务、undo 日志暴涨、主从延迟、甚至 OOM。应拆成小批量，每次控制在 1000–10000 行：
- 用主键 / 自增 ID 分页删除：DELETE FROM t WHERE id BETWEEN ? AND ? LIMIT 1000
- 配合循环脚本或存储过程，每次删除后加短暂停（如SLEEP(0.1)），缓解主从压力
- 避免用 OFFSET 分页（如LIMIT 10000,1000），偏移越大越慢；改用“游标式”：记录上一批最大 id，下一批查WHERE id > last_id ORDER BY id LIMIT 1000
考虑 TRUNCATE 或 DROP+RECREATE 替代
如果要清空整表或满足特定条件的大比例数据（如删 90% 以上），DELETE 不是最优选：
- TRUNCATE TABLE极快，不走事务、不记 undo、重置自增 ID，但不能带 WHERE 且会隐式提交
- 按条件大批量清理：可创建新表CREATE TABLE t_new AS SELECT * FROM t WHERE keep_condition，再原子替换（RENAME TABLE t TO t_bak, t_new TO t）
- 注意：TRUNCATE 和 DROP 会释放磁盘空间；DELETE 只是标记删除，需后续 OPTIMIZE TABLE 或开启 innodb_file_per_table 并等待 Purge 线程回收
调优相关配置与环境
部分参数直接影响 DELETE 性能，特别是高并发场景：
- 增大innodb_buffer_pool_size，让热数据常驻内存，减少磁盘读取
- 适当调高innodb_log_file_size，避免频繁刷 log 导致阻塞
- 确认autocommit=1（默认），避免意外大事务；若手动事务，务必及时 COMMIT
- 删除前关闭唯一性约束检查（仅限可信数据）：SET UNIQUE_CHECKS=0，删完再开，但需谨慎评估一致性风险
