什么时候更喜欢悲观的事务隔离模型而不是乐观的模型？

Question

我是否正确地理解表/行锁提示正被用于并发的悲观事务(TX)隔离模型(仅用于)

换句话说，在SQL Server (2005及更高版本)提供的乐观TX隔离过程中，何时可以使用表/行锁提示？

如果后者提供内置的乐观(也称为快照，也称为版本控制)并发隔离，则需要在SQL Server2005+中使用悲观的TX隔离级别/提示？

我确实读过悲观的选择是遗产，不再需要了，尽管我有疑问。

另外，当需要手动编写乐观并发特性的时候，使用内置在SQL Server2005+中的乐观(也称为快照版本控制) TX隔离级别？

最后一个问题的灵感来源于阅读：

• “SQL Server中的乐观并发”(2007年9月28日)

描述用于在Server中提供版本控制的自定义编码。

Answer 1

乐观并发需要更多的资源，冲突发生时成本更高。

两个会话可以读取和修改值，冲突只有在尝试同时应用更改时才会发生。这意味着，在并发更新的情况下，两个值都应该存储在某个地方(当然，这需要资源)。

而且，当发生冲突时，通常应该回滚整个事务或重新获取游标，这也是很昂贵的。

悲观并发模型使用锁定，从而降低并发性，但提高了性能。

对于两个并发任务，第二个任务等待锁释放可能比在两个同时工作上花费CPU时间和磁盘I/O更便宜，然后更多地用于回滚不太幸运的工作并重新执行它。

比方说，您有这样的查询：

UPDATE  mytable
SET     myvalue = very_complex_function(@range)
WHERE   rangeid = @range

，使用very_complex_function从mytable本身读取一些数据。换句话说，此查询转换共享mytable值的range的子集。

现在，当两个函数在相同的范围内工作时，可能有两种情况：

1. 悲观:第一个查询锁定，第二个查询等待它。第一个查询在10秒内完成，第二个查询也完成。总计：20秒。
2. 乐观:这两个查询都独立工作(在相同的输入上)。这在它们之间共享CPU时间，并在交换时增加一些开销。他们应该将中间数据保存在某个地方，这样数据就会存储两次(这意味着两次I/O或内存)。假设两者几乎同时完成，以15秒为单位。 但是，当提交工作时，第二个查询将发生冲突，并不得不回滚其更改(例如，使用相同的15秒)。然后，它需要重新读取数据，并使用新的数据集(10秒)再次执行工作。 因此，这两个查询完成的时间都要晚于悲观锁定：15和40秒与10和20。

如果后者提供内置的乐观(也称为快照，也称为版本控制)并发隔离，则需要在SQL Server2005+中使用悲观的TX隔离级别/提示？

乐观的孤立程度是乐观的。当您期望您的数据上的高争用时，不应该使用它们。

顺便说一句，SQL Server 2000中也提供了乐观隔离(用于读取查询)。

Answer 2

我在这里有一个详细的答案：开发并发性的修改

Answer 3

我想这里的术语有点混乱。

乐观锁定/乐观并发/.是一种用于避免以下情况的编程技术：

• 启动事务
• 读取数据，设置“读取”锁，以防止对数据的任何删除/修改。
• 在用户屏幕上显示数据
• 等待用户输入，锁保持活动状态。
• 继续等待用户输入，锁仍然阻止任何写入/修改。
• 用户输入永远不会出现(无论出于什么原因)
• 事务超时(这通常不是很快，因为必须给用户输入输入的合理时间)。

乐观锁定将此替换为以下内容：

• 启动事务读取
• 读取数据，设置“读取”锁，以防止对数据的任何删除/修改。
• 结束事务读取，释放刚刚设置的读锁
• 在用户屏幕上显示数据
• 等待用户输入，但其他事务可以同时修改/删除数据
• 用户输入到达
• 启动事务写入
• 验证数据是否未被更改，如果有异常，则引发异常。
• 应用用户更新
• 终端事务写入

因此，单个“用户事务”将获取某些数据，并对其进行更改和更新，由两个不同的“数据库事务”组成。通常所说的“隔离级别”适用于这些数据库事务。您所指的“乐观锁定”适用于“用户事务”。

这一问题更加复杂，因为从广义上讲，“隔离数据库交易部分”有可能采取两种完全不同的战略：

• MVCC
• 2相锁定

我认为“快照版本控制隔离级别”意味着MVCC技术(嗯，其各种可能的变体之一)正被用于数据库事务。其他常见的隔离级别更适用于使用2PL作为序列化(/isolation)技术的事务隔离。(把它们混为一谈可能会变得混乱.)