MySQL中UPDATE加LIMIT仅适用于单表且需配合ORDER BY保证顺序；PostgreSQL须用CTE+子查询实现；SQL Server用TOP(n)且必须紧接UPDATE后；跨库推荐基于主键分批更新并校验影响行数。
MySQL 用 LIMIT 控制 UPDATE 行数，但有严格限制
MySQL 支持在 UPDATE 语句末尾加 LIMIT，例如：
UPDATE users SET status = 'archived' WHERE created_at < '2020-01-01' LIMIT 100;
但注意：这个
LIMIT 只对单表更新生效；如果用了 JOIN，MySQL 会报错 ERROR 1221 (HY000): Incorrect usage of UPDATE and LIMIT。另外，
LIMIT 不保证顺序——除非显式加 ORDER BY（MySQL 8.0+ 支持，5.7 及更早版本不支持 ORDER BY + LIMIT 在 UPDATE 中）。所以安全写法是先验证再执行：
SELECT id FROM users WHERE created_at < '2020-01-01' ORDER BY id ASC LIMIT 100;
拿到 ID 列表后，再用
WHERE id IN (...) 更新。
PostgreSQL 没有 LIMIT，得靠 CTE + LIMIT 配合
PostgreSQL 的 UPDATE 语法本身不接受 LIMIT 或 ORDER BY。必须借助 WITH 子句构造临时结果集：
WITH candidates AS ( SELECT id FROM users WHERE created_at < '2020-01-01' ORDER BY id LIMIT 100 ) UPDATE users SET status = 'archived' WHERE id IN (SELECT id FROM candidates);
关键点：
-
WITH中的SELECT必须包含能唯一标识行的字段（通常是主键） - 如果表有并发写入，CTE 查询和后续 UPDATE 之间存在时间窗口，可能漏更新或重复更新（需配合事务隔离级别或
SELECT ... FOR UPDATE） - 不要省略
ORDER BY，否则LIMIT返回的行不确定
SQL Server 用 TOP，但不能直接跟 WHERE
SQL Server 使用 TOP，但语法和 MySQL 完全不同：
UPDATE TOP (100) users SET status = 'archived' WHERE created_at < '2020-01-01';
注意：
-
TOP必须紧跟UPDATE关键字后，不能放在WHERE后面 - 不支持
TOP+ORDER BY直接控制顺序（因为 UPDATE 本身无序），想按时间删旧数据，得嵌套子查询或用 CTE - 更稳妥的方式是先查出 top 行 ID：
UPDATE u SET status = 'archived' FROM users u INNER JOIN ( SELECT TOP 100 id FROM users WHERE created_at < '2020-01-01' ORDER BY created_at ) t ON u.id = t.id;
跨数据库通用方案：分批 + 事务 + 主键范围
依赖 LIMIT / TOP 的写法移植性差，且高并发下风险高。生产环境推荐更可控的方式：
- 始终基于主键（如
id）做范围分片，例如每次更新WHERE id BETWEEN 10000 AND 10099 - 每次操作包裹在事务中，并检查
ROW_COUNT()（MySQL）、@@ROWCOUNT（SQL Server）或GET DIAGNOSTICS（PostgreSQL）确认实际影响行数 - 避免用
OFFSET分页式更新（性能随偏移量增大急剧下降） - 如果目标是“只改前 N 条”，务必先
SELECT ... ORDER BY ... LIMIT 1确认排序逻辑是否符合业务预期——时间字段可能有重复值，导致非确定性结果
实际执行时最容易被忽略的是：没验证排序字段的唯一性，也没加事务保护，结果在并发场景下多改或少改了几行，还难以回溯。
