MySQL中DELETE支持LIMIT限制行数，但仅适用于单表删除，必须配合ORDER BY确保顺序可控，且需在事务中执行以防误删；PostgreSQL需用CTE先选ID再删；SQL Server用TOP并配合CTE实现类似效果。
MySQL中用LIMIT限制DELETE影响行数
MySQL的DELETE语句原生支持LIMIT子句，这是最直接的方式。但要注意：它只在单表删除时有效，多表DELETE语法不支持LIMIT（会报错ERROR 1221 (HY000): Incorrect usage of UPDATE and LIMIT）。
常见误操作是写成DELETE FROM t WHERE status = 'old' LIMIT 100却忘了加事务保护——万一条件写错，删完才发现没备份就晚了。
- 必须搭配
BEGIN; ... COMMIT;或START TRANSACTION;使用 -
LIMIT值必须是常量，不能是变量或子查询（如LIMIT @n在预处理语句外无效） - 若WHERE条件匹配0行，
ROW_COUNT()返回0，不会报错
PostgreSQL中用CTE + LIMIT实现安全删除
PostgreSQL不支持DELETE ... LIMIT语法，但可以用WITH子句先选出行再删。关键点在于：CTE里的LIMIT作用于SELECT结果，而DELETE通过USING关联这些ID，从而控制实际删除数量。
示例：
WITH candidates AS ( SELECT id FROM orders WHERE created_at < '2023-01-01' ORDER BY id LIMIT 1000 ) DELETE FROM orders USING candidates WHERE orders.id = candidates.id;
注意：ORDER BY不能省略，否则LIMIT行为不可预测；且id必须是主键或有索引，否则性能极差。
- 如果表无主键，改用
ctid（但仅限当前事务可见，不可跨会话复用） - 并发环境下，CTE查出的ID可能被其他事务修改，建议加
FOR UPDATE锁（需放在子查询里） - 不要用
OFFSET分页式删除，容易漏数据或重复删
SQL Server中用TOP配合循环批量删除
SQL Server支持DELETE TOP (n)，但它不是标准SQL，且TOP不保证顺序——除非显式加ORDER BY（但DELETE TOP本身不接受ORDER BY）。所以正确做法是用WHERE id IN (SELECT TOP (n) id ... ORDER BY id)结构，或更稳妥的循环方式。
推荐写法（带事务与计数）：
DECLARE @batch_size INT = 500; WHILE @@ROWCOUNT > 0 BEGIN DELETE TOP (@batch_size) FROM logs WHERE created_at < DATEADD(day, -30, GETDATE()); END
这里@@ROWCOUNT检查上一批是否删了行，避免无限循环。但要注意：TOP在子查询中必须加括号，TOP 500写法在某些旧版本会报错。
- 不加
WAITFOR DELAY '00:00:00.01'可能导致锁争用加剧 - 若日志表有触发器，
TOP删除会逐行触发，影响性能 - 无法用
OUTPUT子句捕获被删行的完整数据（只能输出列，不能含LOB）
通用原则：为什么不能只靠LIMIT防误删
LIMIT或TOP只是刹车，不是安全带。真正容易被忽略的是执行前的验证环节。
- 任何删除前，先跑
SELECT COUNT(*)和SELECT * LIMIT 5确认范围 - WHERE条件里避免隐式类型转换（比如
WHERE user_id = '123abc'可能全表扫描并删空） - 生产环境禁止用
DELETE FROM table，哪怕加了LIMIT——优化器可能忽略它 - 自动清理任务必须设超时（如pg_cron里加
statement_timeout），防止长事务阻塞VACUUM
最危险的情况是：你写了LIMIT 100，但WHERE条件没索引，数据库扫了1000万行才凑够100条匹配——这时LIMIT没起作用，IO和锁已经打满。
