‘'Lost’vs‘写倾斜’

Question

有人能解释一下数据库事务理论中的“丢失更新”和“写斜”到底有什么区别吗？谁能给我举个例子吗？

Answer 1

非正式地说，丢失了更新和写斜是并发写事务相互干扰的方式。

当基于陈旧数据的事务中进行更新时，就会发生写斜。Stale数据是由事务读取的值，该值由于并发事务的后续提交写入而变得陈旧。

当一个事务写入的提交值被并发事务的后续提交写入覆盖时，丢失更新。事实上，丢失的更新实际上是写斜的特例；其中更新应用于已经过时的数据。

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

库存表有一个"ProductId“列和一个"InStock”列，它们计算特定产品当前库存的项目数。每个购买(事务)都会将"InStock“值减去购买的项目数。

假设商店里有两台电动剃须刀(特定型号的)库存。

两位顾客同时购买其中一台剃须刀。

每个并发购买(事务)从剃须刀的"InStock“记录读取相同的值(两个)。每个事务减少"InStock“计数器并将更新的值(一个)提交到数据库。在两个并发事务都已提交后，计数器将错误地指示剃须刀仍在库存(还剩一项)。

更新之一是lost。

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

事务隔离是一个深层次的话题。。

此外，假设数据库将库存历史记录在InventoryHistory表中。InventoryHistory表的列为“时间戳”、"ProductId“和"InStock”(购买后仍保留)。根据设计，InventoryHistory表的更新是购买事务中的最后一次操作。在两个事务提交之后，各自的InventoryHistory记录将分别反映一个"Instock“值1 --这是不正确的，因为其中一个记录应该反映"Instock”值为零。不正确的InventoryHistory记录是写斜的一个例子。

在这种情况下，快照隔离不会阻止异常数据被写入数据库，因为没有更新是丢失。相反，写入的数据是异常的，因为事务读取的值已经过时--这是写斜交。快照隔离不会阻止写入倾斜的。为了防止写错，数据库必须实现可序列化的隔离。

读这篇文章对写倾斜、序列化和快照隔离进行了严格的讨论。