MySQL单表DELETE支持LIMIT，但必须配合ORDER BY才能确保删除顺序；多表DELETE不支持LIMIT，需用子查询分步实现；LIMIT仅限制数量，不提供事务回滚或业务校验。
MySQL 用 LIMIT 最直接，但只对单表有效
MySQL 的 DELETE 原生支持 LIMIT，写法简单：DELETE FROM logs WHERE created_at 。但它有硬限制：仅适用于单表删除，多表语法（如 <code>DELETE t1 FROM t1 JOIN t2...）加 LIMIT 会报错 ERROR 1221 (HY000): Incorrect usage of LIMIT and UPDATE/DELETE。
容易踩的坑：
-
LIMIT不带ORDER BY时删的是物理存储顺序前 N 行，业务上不可控（比如想删最早日志，却删了最新几条） -
LIMIT后不能直接跟变量，LIMIT @n会报错；必须用PREPARE+EXECUTE动态执行 - 如果
WHERE字段没索引，优化器可能放弃使用LIMIT，仍全表扫描——锁和日志压力照旧
PostgreSQL 必须用子查询或 CTE 模拟 LIMIT
PostgreSQL 的 DELETE 不支持 LIMIT，硬加会报 ERROR: syntax error at or near "LIMIT"。必须靠子查询兜底：DELETE FROM orders WHERE id IN (SELECT id FROM orders WHERE status = 'cancelled' ORDER BY id ASC LIMIT 500)。
关键点：
-
ORDER BY+LIMIT必须出现在子查询里，否则IN结果无序，删哪几行不确定 -
id字段必须有索引，否则子查询全表扫描代价极高 - 避免用
OFFSET分页式删（如OFFSET 1000 LIMIT 500），OFFSET越大越慢，不适合批量清理 - 极端场景下可改用
ctid（如SELECT ctid FROM orders LIMIT 500），适合无主键或主键未索引的大表
SQL Server 用 TOP，括号和位置不能错
SQL Server 支持 TOP，但语法比 MySQL 更严格：DELETE TOP (200) FROM products WHERE stock = 0 是合法的；DELETE TOP 200 FROM ...（缺括号）直接报错。
按时间等业务顺序删时，TOP 本身不支持 ORDER BY，必须嵌套 CTE：WITH cte AS (SELECT TOP (100) id FROM sales ORDER BY created_at ASC) DELETE FROM sales WHERE id IN (SELECT id FROM cte)。
注意：
-
TOP值可以是变量：DELETE TOP (@batch_size) FROM ...，适合循环脚本控制批次大小 - 没加
ORDER BY时，TOP行为未定义，实际按物理顺序取，不可靠 - CTE 中的
TOP必须带ORDER BY，否则每次执行结果可能不同
跨数据库通用方案：循环 + 显式计数控制
当需要兼容多种数据库，或业务要求“必须删满 N 行才停”（比如日志清理要确保每批恰好删 5000 条），就不能依赖方言特性。得靠应用层循环控制，每次执行后检查 ROW_COUNT()（MySQL）、GET DIAGNOSTICS（PG）或 @@ROWCOUNT（SQL Server）。
核心逻辑一致：
- 每次执行一个带范围条件的
DELETE（如id BETWEEN ? AND ?），而非依赖LIMIT/TOP - 基于索引字段分片，保证批次不重叠、不遗漏（例如用主键或时间戳递增字段）
- 每批独立事务，执行后 sleep 几百毫秒，给数据库“喘气”机会
- 监控
information_schema.INNODB_TRX（MySQL）或pg_stat_activity（PG）确认锁是否及时释放
真正难的不是“怎么写那条语句”，而是确认它真的在分批生效——你得亲眼看到锁等待下降、WAL/redo 写入速率回落、主从延迟不再飙升。否则，LIMIT 1000 只是一行安慰剂代码。
