答案。

问题历史：

在迁移、迁移和修复业务逻辑时，批量更新数据是非常需要的。典型的例子是：需要在不中断服务、保持可用性和性能的情况下，变更工作表中数千万行的状态。

问题：

普通的UPDATE没有限制时运行缓慢，可能导致锁定升级，锁定表并在出错时导致集体回滚。需要一种方法来最小化对用户的影响，并确保事务性。

解决方案：

通过WHERE和LIMIT/TOP将操作分为批次。
使用窗口函数、临时表、临时标记。
有时——暂时禁用索引，设置保存点（SAVEPOINT），使用更低的隔离级别。

代码示例：

-- 每批更新10,000行的示例
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

关键特性：

批处理降低了锁定持续时间
原子性仅在每个小事务的范围内得到保证
在某些数据库系统中，有特殊的批量操作符，可以加快大批量数据的处理

有陷阱的问题。

可以在一个事务中进行批量UPDATE而不锁定表吗？

通常情况下，不能。大型事务会锁定表/页面，并增加锁定和超时的风险。最好使用批处理。

索引的存在会影响批量更新的速度吗？

会。对索引字段的任何更新都需要为每一行重建索引。有时，暂时删除索引是合理的，但这需要深入分析。

在批量更新时，所有行都是原子的更新吗？

不，原子性仅在一个批次的范围内得到保证（行/事务的限制）。如果批次中断，部分行将被更新，部分将不会。对于真正的原子性——只有在一个事务中完成完整的UPDATE，这在处理大规模数据时是危险的。

常见错误和反模式

没有限制的瞬时UPDATE，导致锁定升级
忽视索引——在可索引列上期待高性能
不使用保存点（SAVEPOINT）

生活中的例子

负面案例

技术工程师决定在生产数据库中用一个请求更新1000万行：UPDATE mytable SET status = 'archived'。网站“冻结”，回滚花费了几十分钟，性能受影响。

优点：

命令简单，代码量最少 缺点：
冻结/锁定生产服务
在错误情况下可能会导致大量事务回滚

正面案例

请求被分成每批10000行，短期事务内的更新在工作时间进行，没有停机。