MySQL单表DELETE支持LIMIT，但必须配合ORDER BY才能确保删除目标行；多表DELETE不支持LIMIT，硬写会报ERROR 1064；ORDER BY字段需有索引，推荐主键或时间字段；分批建议LIMIT 1000–5000并用WHERE id > last_id续删。
MySQL 单表 DELETE 支持 LIMIT，但必须配合 ORDER BY 才能确保删的是你想要的那几行；多表 DELETE 完全不支持 LIMIT，硬写会直接报错 ERROR 1064。
单表 DELETE + LIMIT 必须带 ORDER BY
不加 ORDER BY 的 DELETE ... LIMIT 行为不可控——MySQL 可能每次选不同行删，尤其在 InnoDB 中，物理顺序不等于插入顺序，更不等于业务时间顺序。
- 错误写法：
DELETE FROM logs WHERE status = 'error' LIMIT 100（删哪 100 行？没人知道） - 正确写法：
DELETE FROM logs WHERE status = 'error' ORDER BY id ASC LIMIT 100（删 id 最小的 100 条） -
ORDER BY字段必须有索引，否则会触发filesort，扫描变慢、锁住更多行 - 推荐用主键或时间字段（如
created_at），且该字段需建索引
多表 DELETE 不能直接用 LIMIT
像 DELETE t1, t2 FROM t1 JOIN t2 ON ... LIMIT 10 这种写法，在所有 MySQL 版本中都会报错 ERROR 1064。官方明确禁止。
- 替代方案是用派生表兜一圈：
DELETE t1 FROM t1 INNER JOIN (SELECT id FROM t2 WHERE flag = 1 ORDER BY updated_at ASC LIMIT 10) t2 ON t1.ref_id = t2.id - 子查询里的
LIMIT必须在括号内，且ORDER BY要写在子查询里，外部不能加 - 如果子查询字段没索引，
SELECT id FROM t2 WHERE ... ORDER BY ... LIMIT 10可能全表扫描，拖垮性能
分批删除的实用参数与节奏控制
批量大小不是越大越好，也不是越小越安全——它得平衡事务开销、锁持有时间和运维可控性。
- 建议每批
LIMIT设为1000–5000：太小（如 100）导致网络/解析开销占比过高；太大（如 10000+）易触发lock wait timeout或被 DBA 中断 - 每批执行后加
SLEEP(0.1)（应用层控制），避免 CPU 和 I/O 突增；MySQL 存储过程里不推荐用SLEEP()，调试困难 - 不要用
LIMIT offset, count（如LIMIT 10000, 1000），越往后偏移越慢，还可能漏删或重复删 - 更稳的模式是
WHERE id > last_id ORDER BY id LIMIT N，用上一批最后删掉的id作为下一批起点
删完数据，磁盘空间没变小是正常现象
InnoDB 删除只是把页内记录标记为“可复用”，不会立刻归还空间给操作系统。业务侧看到磁盘没释放，不是语句写错了，而是机制如此。
- 想真正回收空间，得执行
OPTIMIZE TABLE your_table或ALTER TABLE your_table ENGINE=InnoDB - 但这两个操作会锁表、重建整张表，大表慎用；生产环境建议走主从切换或 pt-online-schema-change
- 日常运维中，只要
ROW_COUNT()返回值稳定、无报错，就说明LIMIT删除逻辑本身已生效
