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

标签 sql database transactions lost-update write-skew

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

最佳答案

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

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

丢失更新 当一个事务写入的提交值被并发事务的后续提交写入覆盖时,就会发生这种情况。事实上,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用于对写偏斜、可串行化和快照隔离的严格讨论。

关于sql - “丢失更新”与 'Write skew',我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27826714/

相关文章:

c# - Linq数据库插入错误

database - 使用 NHibernate 创建数据库 View

PHP + MySQL 事务示例

sql - 在 1 个表扫描中对多个列操作进行分组

带日期的 Mysql 查询优化

mysql - CREATE TABLE 一次但 INSERT INTO 两次

javascript - 是否可以使用代码来转换格式为 'list' : "translation"? 的列表

java - 可靠地跟踪 Hibernate 所做的更改

java - 在 Oracle 上使用 Hibernate 的死锁事务

sql - Guid 主键/外键困境 SQL Server