sql - “丢失更新”与 'Write skew'

Question

有人能给我解释一下 a 和 a 之间的区别吗数据库事务理论中的“丢失更新”和“写入偏斜”？有人可以给我举个例子吗？

Answer 1

通俗地说，丢失更新和写入偏差是并发写入事务相互干扰的方式。

写入偏差 发生在基于陈旧数据 的事务中进行更新时。陈旧数据 是由事务读取的值，由于并发事务的后续提交写入而变得陈旧。

丢失更新 当一个事务写入的提交值被并发事务的后续提交写入覆盖时，就会发生这种情况。事实上，lost update确实是write skew的特例；更新应用于已过时的数据。

考虑零售商店的数据库维护库存 表的情况。数据库没有实现事务隔离。

Inventory 表有一个“ProductId”列和一个“InStock”列，用于计算特定产品当前的库存数量。每次购买(交易)都会将“InStock”值减少购买的商品数量。

假设商店有两台电动 Razor (特定型号)。

两位顾客同时购买其中一把 Razor 。

每个并发购买(交易)都从 Razor 的“InStock”记录中读取相同的值(两个)。每个事务都会递减“InStock”计数器并将更新后的值(一)提交给数据库。在两个并发事务都已提交后，计数器将错误地指示 Razor 仍在库存中(还剩一件)。

其中一个更新丢失。

假设数据库实现快照隔离(带有丢失更新检测)，在这种情况下丢失更新不会发生。这是因为快照隔离 检测何时发生丢失更新。在事务提交数据后，尝试提交对相同数据的写入的并发事务将被数据库中止。在我们的示例中，事务被中止的进程启动一个新事务以重新读取“InStock”列，将其递减，然后提交更新后的值。假设没有其他冲突，此更新记录的尝试会成功提交，并且“Instock”列包含(正确的)值零。

Transaction isolation is a deep topic .

进一步假设数据库在 InventoryHistory 表中记录库存历史。 InventoryHistory 表包含“Timestamp”、“ProductId”和“InStock”列(购买后)。按照设计，对 InventoryHistory 表的更新是购买交易中的最后一个操作。两个事务提交后，相应的 InventoryHistory 记录将分别反射(reflect)“Instock”值为 1——这是不正确的，因为其中一个记录应反射(reflect)“Instock”值为零。不正确的InventoryHistory 记录是写入偏差 的一个示例。

在这种情况下，快照隔离并未阻止将异常数据写入数据库，因为没有更新丢失。相反，写入的数据异常是因为事务读取的值已经过时——这就是写入偏差。 快照隔离 不能防止写入偏差。为防止写入倾斜，数据库必须实现可序列化隔离。

Read this article用于对写偏斜、可串行化和快照隔离的严格讨论。