真正有效的优化是绕开delete底层开销：优先用truncate清空整表、分区表用drop partition秒删、大表重建替换，或确保where走索引后分批删除（order by+limit+sleep），避免全表扫描、undo日志膨胀与锁竞争。
直接在大表上执行 DELETE 是最常见也最危险的负载来源——它不光慢，还会拖垮整个数据库。真正有效的优化不是“让 DELETE 变快”，而是绕开它的底层开销：undo 日志、索引维护、行锁堆积和全表扫描。
WHERE 条件没走索引导致全表扫描
执行 DELETE FROM logs WHERE status = 'archived' 卡住几秒甚至更久？大概率是 status 列没索引。数据库得逐行扫描才能找出匹配项，每扫一行都触发锁、日志写入和事务开销。
- 先用
EXPLAIN DELETE FROM logs WHERE status = 'archived'看type是否为ALL—— 这就是全表扫描信号 - 如果
status只有 2–3 个值（如'active'/'archived'），单列索引效果有限；但若状态分布较散（比如订单含 10+ 种状态），且常按某几种过滤，索引就值得建 - 避免函数导致失效：写成
WHERE DATE(created_at) = '2024-05-01'就白搭，哪怕created_at有索引；应改用范围查询：created_at >= '2024-05-01 00:00:00' AND created_at - 隐式类型转换也会丢索引：比如
WHERE user_id = '123'（user_id是INT），应统一写成WHERE user_id = 123
分批删除必须带 ORDER BY + LIMIT，不能只靠 LIMIT
只写 DELETE FROM orders WHERE status = 'archived' LIMIT 10000 是危险的。MySQL 不保证无序删除的稳定性——可能漏删、重复删，或因执行计划变化导致批次重叠。
- 必须加
ORDER BY id ASC或ORDER BY create_time ASC（字段需有索引且单调）确保每次删的是确定范围的连续主键 - 绝对不用
LIMIT 10000 OFFSET 100000：OFFSET 越大越慢，本质是跳过前 N 行再扫，等于白加 LIMIT - 推荐写法：
DELETE FROM orders WHERE id BETWEEN 1000001 AND 1100000 LIMIT 10000，或DELETE FROM logs WHERE create_time - 每次执行后查
SELECT MAX(id) FROM ...获取下一批起点，别依赖自增步长 - 每批后加
SLEEP(0.1)（MySQL）或应用层延时，给 checkpoint 和日志截断留出窗口
删大部分数据时，TRUNCATE + INSERT 比 DELETE 更高效
你要保留不到 20% 的数据（例如只留最近 90 天），DELETE 就是错的选择。新建表导入再切换，I/O 和锁开销几乎为零。
- 步骤：
CREATE TABLE orders_new LIKE orders→INSERT INTO orders_new SELECT * FROM orders WHERE create_time >= '2024-07-01'→RENAME TABLE orders TO orders_old, orders_new TO orders→DROP TABLE orders_old - 优势：不走逐行 DML，无 undo 日志膨胀，不锁全表
- 缺点：需要双倍磁盘空间，且期间需停写或加应用层切换逻辑
- 注意：该操作不可回滚，但比
DELETE安全——它只是删数据文件，不碰 buffer pool
分区表优先用 DROP PARTITION，而不是 WHERE 删除
如果表按时间做了 RANGE 或 LIST 分区（比如按年/月分），DROP PARTITION 是秒级操作，不走 DML 流程，也不生成 undo 日志。
- 确认分区定义：
SHOW CREATE TABLE logs - 然后直接删整块：
ALTER TABLE logs DROP PARTITION p2022 - 该操作不可回滚，但比
DELETE安全——它只是删数据文件，不碰 buffer pool - 不能和
WHERE混用；若只需删某分区中部分数据，先EXCHANGE PARTITION导出子集再处理 - MySQL 5.7+ 支持，但分区字段必须是整型或可转为整型的表达式（如
YEAR(create_time)）
最容易被忽略的是配套动作：光调 SQL 不够，innodb_log_file_size 太小、binlog_format 为 STATEMENT、未关闭自动统计更新，都会让分批删除照样翻车。真实生产环境几乎从不用单条大 DELETE。
