SQL Server 2005+ 支持 UPDATE TOP(N)，但需括号包裹变量、不保证顺序，须配合子查询+ORDER BY实现有序更新；禁用SET ROWCOUNT；大批量更新需分批、加索引、控事务。
UPDATE 里用 TOP 是最直接的方式
SQL Server 2005 及以后版本支持在 UPDATE 语句中直接使用 TOP，语法简单、语义明确，且不依赖会话级设置。
-
TOP后面的数字是**行数**，不是百分比；如需百分比，得写TOP (10) PERCENT -
TOP不保证顺序——除非配合子查询 +ORDER BY，否则更新的是“任意满足条件的前 N 行” - 不能直接写
UPDATE TOP (@n) ...，变量必须包裹在括号里：UPDATE TOP (@n)✅，UPDATE TOP @n❌ - 若 WHERE 条件匹配 0 行，
TOP (100)也不会报错或警告，只是实际影响 0 行
别再用 SET ROWCOUNT 控制 UPDATE
SET ROWCOUNT 在 SQL Server 2012+ 已被明确标记为“不推荐用于 DML”，2025 年后可能彻底失效。它的问题不止是过时：
- 作用域是整个会话，容易漏掉
SET ROWCOUNT 0恢复，导致后续语句意外截断 - 对触发器也生效，可能让触发逻辑只跑一半，行为难以预测
- 和
TOP共存时，ROWCOUNT优先级更高，但这种叠加毫无意义，纯属陷阱 - 在包含 CTE 或 OUTPUT 子句的 UPDATE 中，
ROWCOUNT行为不稳定，文档都未明确定义
需要按顺序更新前 N 行？必须用子查询 + ORDER BY
UPDATE TOP (N) 本身不排序，所以“更新最早创建的 10 条记录”这类需求不能只靠 TOP。正确写法是把排序逻辑放进派生表或 CTE：
UPDATE t SET status = 'processed' FROM ( SELECT TOP (10) id FROM orders WHERE status = 'pending' ORDER BY created_at ASC ) AS t2 INNER JOIN orders AS t ON t.id = t2.id;
- 不能写成
UPDATE TOP (10) ... ORDER BY created_at—— 语法错误，SQL Server 不允许 - CTE 方式更清晰，但注意：CTE 必须可更新（比如不能含聚合、DISTINCT、窗口函数等）
- 如果
created_at有重复值，加上id作为二级排序，避免结果不确定
大批量更新时，分批控制比单次限制更重要
想更新 100 万行？别指望一个 TOP (1000) 就万事大吉。真正要防的是锁升级、日志暴涨和阻塞：
- 单次
TOP (5000)更新比TOP (100000)更安全，但关键是加事务和延时：COMMIT后WAITFOR DELAY '00:00:00.1' - WHERE 条件必须走索引，否则每次扫描全表，性能随批次递减
- 不要用
OFFSET / FETCH模拟分页更新——SQL Server 不支持，强行套 CTE 会导致无法下推过滤条件，锁整张表 - 监控
sys.dm_exec_requests中的wait_type，若频繁出现LCK_M_U或LOG_RATE_GOVERNOR，说明分批粒度还是太大
顺序、索引、事务边界——这三个点漏掉任何一个，TOP 就只是个看起来能用的幻觉。
