答复。

在多个相关表中进行批量数据更新是SQL工业编程中的经典任务。随着业务应用的发展，出现了同时更新大量数据的需求，同时确保其一致性。历史上通过循环场景来处理，这导致了低性能和长时间的锁定。后来出现了高级DML操作（例如MERGE）、事务结构以及使用暂存表的方法。

问题在于数据更新涉及多个具有关系的表（例如订单和订单详细信息），这容易出现"孤立"引用（orphan rows），因锁定造成的性能损失，以及对数据库管理系统的不可预测负载。

解决方案基于使用原子事务、带JOIN条件的UPDATE/DELETE/MERGE操作，以及批量数据处理。一个好的实践是将聚合更改延迟到临时暂存表中，然后通过事务批量应用它们。以下是使用MERGE的SQL Server示例：

BEGIN TRANSACTION;

-- 示例通过MERGE进行主表和相关表的批量更新
MERGE INTO orders AS tgt
USING temp_order_updates AS src
  ON tgt.id = src.id
WHEN MATCHED THEN
  UPDATE SET tgt.status = src.status, tgt.updated_at = src.updated_at;

MERGE INTO order_details AS tgt
USING temp_detail_updates AS src
  ON tgt.order_id = src.order_id AND tgt.sku = src.sku
WHEN MATCHED THEN
  UPDATE SET tgt.price = src.price, tgt.qty = src.qty;

COMMIT;

关键特性：

将操作隔离在一个事务中：没有中间不一致。
使用暂存表准备可变数据。
应用批量操作以减少锁定和优化负载。

反向提问。

如果对速度的要求很严格，可以先更新主表，然后再单独更新相关表，且不使用事务吗？

在事务外进行单独的UPDATE会在任何阶段出现错误时导致数据严重不一致——例如，如果更新了订单但未更新详细信息，逻辑将被破坏。在现代数据库管理系统中，使用事务几乎不会增加批量处理的开销。

如果执行一个大UPDATE并带有子查询，性能会下降吗？这会导致锁定吗？

是的，大表的单一UPDATE会导致锁定升级，表级锁定以及其他用户的停顿。最好将处理拆分为批次，通过WHERE ... AND rownum/id/limit限制。

批次示例：

UPDATE orders
SET status = 'closed'
WHERE status = 'pending' AND id BETWEEN 100000 AND 199999;

MERGE保证了原子性并正确处理相关表的顺序吗？

不，MERGE在一张表的范围内工作。更新相关表需要单独的MERGE或UPDATE，并且必需将两个操作放在同一个事务中。

常见错误和反模式

在批量修改时缺少事务，导致数据不一致
对巨大的选择进行大量单元UPDATE/DELETE而没有LIMIT/BATCH：锁定和停顿
操作顺序错误（例如，先更新详细信息，然后更新主表）

实际案例

负面案例

公司在不使用事务的情况下对一百万个订单的状态（"已完成"）分别执行请求：首先是主表orders，之后是详细表order_details。负载下服务器"崩溃"——如果失败，详细表仍保留"开放"状态。 优点：

实现简单
最小代码

缺点：

数据不一致，后期调试困难
回滚复杂

积极案例

实施了暂存表，并在事务内进行分组处理。首先计算所有更改并放入临时表中，然后批量更新两个主表。在发生故障时——彻底回滚。 优点：

保证数据的一致性和完整性
方便控制和回滚