分批删除更安全，因其每次事务小、锁持有时间短、日志可控、可人工中断；需配合ORDER BY主键、LIMIT 1000–5000、SLEEP(0.1)及条件字段索引，避免全表扫描与锁升级。
直接 DELETE FROM table WHERE ... 删几百万行，极大概率导致业务卡顿、主从延迟飙升、甚至被 DBA 杀掉连接——这不是性能问题，是锁和日志的连锁失控。
为什么 LIMIT 分批删比全量删更安全
MySQL 的 DELETE 在 InnoDB 中本质是逐行加行锁 + 记录 undo 日志。全量删会把扫描路径上所有匹配行（甚至间隙）长期锁住，其他事务一碰就等；同时生成巨量 binlog 和 redo log，磁盘 IO 和网络复制压力陡增。
分批删的核心价值在于：每次事务小、锁持有时间短、日志写入可控、便于人工干预中断。
-
LIMIT强制限制单次影响行数，避免单事务膨胀 - 配合
ORDER BY primary_key可让扫描有序、减少随机 IO - 每批后加
SLEEP（应用层控制）能缓冲 CPU 和 I/O 峰值 - 条件字段必须有索引，否则
LIMIT也救不了全表扫描
DELETE + LIMIT 的正确写法与常见错误
错：不带 ORDER BY 直接 DELETE FROM logs WHERE create_time —— MySQL 可能每次选不同行删，重复删或漏删都可能，且无法预估进度。
对：显式按主键排序，确保顺序可预期：
DELETE FROM logs WHERE create_time < '2023-01-01' ORDER BY id LIMIT 1000;
关键点：
- 必须有
ORDER BY id（或其他有索引的单调字段），否则LIMIT行为不可控 -
id字段需有索引（通常是主键），否则ORDER BY会触发 filesort，拖慢速度 - 不要用
OFFSET（如LIMIT 10000,1000），越往后偏移越慢，还容易跳过数据 - 批量大小建议 1000–5000，太小（如 100）增加解析/网络开销；太大（如 10000+）易触发长事务告警
主键范围删除比 LIMIT 更高效？看场景
当你要删的数据在主键上高度连续（比如删 id < 1000000 的旧记录），用 WHERE id BETWEEN ? AND ? 确实比 LIMIT 更稳——它不依赖扫描偏移，执行计划更确定，无排序开销。
但注意：
- 若删的是「时间范围」但主键不连续（比如有大量中间 ID 已被删），
BETWEEN会扫很多无效行，效率反不如ORDER BY id LIMIT -
WHERE id > last_id ORDER BY id LIMIT N是更通用的模式，适合大多数日志类表 - 存储过程中用
WHILE循环需谨慎：MySQL 存储过程调试难、监控弱，出错不易定位，推荐优先在应用层（Python/Go/Shell）控制循环和 sleep
删完数据，磁盘空间没释放？这是正常现象
InnoDB 删除数据只是标记为“可复用”，物理空间不会立刻归还给操作系统。你看到 data_length 没变、磁盘占用不降，不是删失败了。
真正回收空间要靠：
-
OPTIMIZE TABLE table_name（会锁表，慎用） -
ALTER TABLE table_name ENGINE=InnoDB（效果同上，新版 MySQL 推荐） - 如果表非常大，且你删了 80% 以上数据，更推荐「新建表插入保留数据」方案，速度快、空间干净、无碎片
最后提醒一句：别在高峰期跑批量删；别信“删完马上 OPTIMIZE”；最重要的是——删之前先备份，哪怕只是 mysqldump -where 导出待删数据快照。删操作不可逆，节奏和观察比命令本身更重要。
