SQL Server中UPDATE TOP(N)是安全可控的批量更新方式，必须加括号、配合显式事务与ORDER BY（通过派生表或CTE实现），批次建议1000–5000行并加WAITFOR DELAY，禁用SET ROWCOUNT。
直接用 UPDATE TOP (N)，别碰 SET ROWCOUNT —— 它在 SQL Server 2012+ 已被标记为不推荐，2025 年后可能彻底失效，且会污染整个会话。
TOP (N) 是唯一安全、明确、可预测的写法
SQL Server 2005 起原生支持 UPDATE TOP (N)，语法直白，作用域清晰，不依赖会话设置。
-
TOP后面必须加括号：写成UPDATE TOP (@n)✅，UPDATE TOP @n❌（语法错误） - 数字是行数，不是百分比；要百分比得写
TOP (10) PERCENT - 如果
WHERE条件没匹配到任何行，TOP (100)也不会报错，只是@@ROWCOUNT返回 0 - 不加排序时，更新的是“满足条件的任意前 N 行”，顺序不可控 —— 这不是 bug，是设计如此
需要按时间/ID顺序更新前 N 行？必须套子查询或 CTE
UPDATE TOP (N) ... ORDER BY ... 是非法语法。SQL Server 不允许在顶层 UPDATE 中直接跟 ORDER BY。
- 正确做法是把排序逻辑放进派生表：
UPDATE t SET status = 'done' FROM (SELECT TOP (5) id FROM orders WHERE status = 'pending' ORDER BY created_at ASC) AS src JOIN orders t ON t.id = src.id - CTE 也可用，但 CTE 必须可更新：不能含
GROUP BY、DISTINCT、聚合函数或窗口函数 - 如果排序字段（如
created_at）有重复值，务必加上主键（如id）作二级排序，否则结果不确定
大批量更新时，单靠 TOP (N) 不够，还得控批次和锁
想更新 50 万行？别只写 TOP (5000) 就跑 —— 锁升级、日志暴涨、阻塞其他事务才是真瓶颈。
- 每次事务控制在 1000–5000 行较稳妥；更新后加
WAITFOR DELAY '00:00:00.1'给系统喘息时间 -
WHERE条件列必须有索引，否则每批都全表扫描，越往后越慢 - 避免用
OFFSET / FETCH模拟分页更新 —— SQL Server 不支持该语法用于UPDATE，强行套 CTE 可能导致优化器无法下推过滤，锁整张表 - 监控
sys.dm_exec_requests，若wait_type频繁出现LCK_M_U或LOG_RATE_GOVERNOR，说明批次还是太大
真正容易被忽略的不是语法怎么写，而是：没有索引的 WHERE 条件 + 无延迟的循环批次 = 隐形死锁源；还有人至今在生产环境用 SET ROWCOUNT，却忘了它对触发器也生效 —— 更新只跑一半，数据状态就已错乱。
