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行：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 用主键/自增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，删完再开，但需谨慎评估一致性风险
