SQL Server中UPDATE TOP(n)必须加ORDER BY，是为了确保扫描起点可预测、范围可控，避免重复或漏更；需用已建索引的列（如id或created_at），不可用函数或低基数列。
直接用单条 UPDATE 更新几十万行以上数据，几乎必然触发锁升级或长事务阻塞，不是慢一点的问题，而是其他查询会卡死。必须分批，且批次逻辑要贴合索引和存储引擎行为。
SQL Server 用 UPDATE TOP(n) 分批时为什么必须加 ORDER BY
SQL Server 允许 UPDATE TOP(n)，但语法上不强制 ORDER BY；不加的话，引擎按内部页顺序扫描，同一批可能重复更新某些行、跳过另一些——尤其在并发写入场景下，id 不连续或有删除空洞时更明显。
-
ORDER BY不是为了“排序结果”，而是让每次扫描起点可预测、范围可控，确保推进逻辑稳定 - 必须用已建索引的列，比如
ORDER BY id（主键）或ORDER BY created_at, id（联合索引覆盖） - 不能用
ORDER BY NEWID()或函数表达式，否则索引失效，退化为全表扫描+大量锁 - 若业务允许，优先选单调递增字段（如自增
id或带索引的created_at），避免用status这类低基数列做排序依据
MySQL 的 LIMIT 在 UPDATE 中为何不能替代范围切割
很多人写 UPDATE ... WHERE status = 'pending' LIMIT 1000，以为只锁 1000 行——错。InnoDB 仍要扫描所有 status = 'pending' 的行来数够 1000 条，过程中对每行加临键锁（next-key lock），实际锁住的远不止 1000 行。
- 真正安全的做法是：先用
SELECT id FROM t WHERE status = 'pending' ORDER BY id LIMIT 1000拿出 ID 列表，再UPDATE ... WHERE id IN (…) - 或者更推荐：用主键范围切割，如
WHERE status = 'pending' AND id BETWEEN 100000 AND 104999，前提是id有索引且分布相对均匀 -
LIMIT只控制修改行数，不控制扫描和加锁范围；没索引的WHERE条件 +LIMIT是“伪分批”，锁压力反而更大 - 如果
status列没有索引，先加索引比硬写分批脚本更治本（但注意ALTER TABLE加索引本身也会锁表）
分批循环里用 @@ROWCOUNT 还是计数器判断终止
用硬算总行数再除以批次大小来控制循环次数，是常见错误。因为 WHERE 条件可能随更新动态变化（比如 status 改了之后，后续批次查不到原条件匹配的行），导致漏更或死循环。
- SQL Server 必须用
IF @@ROWCOUNT = 0 BREAK，这是唯一可靠的终止信号 - MySQL 应用层需检查
ROW_COUNT()返回值，为 0 时退出，不要依赖SELECT COUNT(*)预估总数 - 如果更新逻辑涉及多表关联或子查询，
@@ROWCOUNT/ROW_COUNT()只反映最后一条语句影响行数，务必放在UPDATE后立刻读取 - 别在循环里反复查
MIN(id)/MAX(id)，这会引入额外扫描和竞争；用上一批最大id值作为下一批起点更轻量
最容易被忽略的是：分批本身不解决索引缺失问题。哪怕你拆成每批 100 行，只要 WHERE 条件没走索引，每批仍会扫全表——只是把一次大锁，拆成一百次小锁而已。先确认执行计划里的 key 字段非空，再谈分批。
