为什么乐观锁比悲观锁快？

Question

如果记录当前正被另一个进程使用，两种形式的锁定都会导致进程等待记录的正确副本。对于悲观锁定，锁定机制来自数据库本身（本地锁定对象），而对于乐观锁定，锁定机制是某种形式的行版本控制，例如时间戳，用于检查记录是否“过时”。

但两者都会导致第二个进程挂起。所以我问：为什么乐观锁定通常被认为比悲观锁定更快/更好？并且，是否存在悲观优于乐观的用例？提前致谢！

Answer 1

你误解了乐观锁。

乐观锁定不会导致事务相互等待。

乐观锁定可能会导致事务失败，但它这样做时从未采取过任何“锁定”。如果事务因乐观锁定而失败，则需要用户重新开始。“乐观”一词正是源于这样一种期望，即由于这个原因导致交易失败的条件只会在非常特殊的情况下发生。“乐观”锁是这样一种方法，它说“我不会使用实际的锁，因为我希望它们无论如何都不需要。如果事实证明我错了，我会接受不可避免的失败。”。

Answer 2

重复问题来自：

/sf/ask/9053061/

从上面的链接复制/粘贴答案：

乐观锁定是一种策略，您可以在其中读取记录、记下版本号并在回写记录之前检查版本是否未更改。当您写回记录时，您会过滤版本上的更新以确保它是原子的。（即在您检查版本并将记录写入磁盘之间没有更新）并一次更新版本。

如果记录是脏的（即与您的版本不同），您可以中止事务，用户可以重新启动它。

此策略最适用于大容量系统和三层体系结构，在这些系统中，您不必为会话维护与数据库的连接。在这种情况下，客户端实际上无法维护数据库锁，因为连接是从池中获取的，并且您可能没有使用从一次访问到下一次访问的相同连接。

悲观锁定是当您锁定记录以供您独占使用，直到您完成它为止。它比乐观锁具有更好的完整性，但要求您小心设计应用程序以避免死锁。要使用悲观锁定，您需要直接连接到数据库（通常在两层客户端服务器应用程序中就是这种情况）或可以独立于连接使用的外部可用事务 ID。

在后一种情况下，您使用 TxID 打开事务，然后使用该 ID 重新连接。DBMS 维护锁并允许您通过 TxID 重新选择会话。这就是使用两阶段提交协议（例如 XA 或 COM+ 事务）的分布式事务的工作方式。

编辑（添加更多信息以解决性能问题）：

性能明智取决于您的环境。考虑以下因素来决定：

由于在大多数情况下并发，您会发现乐观会更好。但是，根据 RDBMS 和环境，这可能会降低或提高性能。通常使用乐观锁定，您会发现该值需要在某处进行行版本控制。

以 MS SQL Server 为例，它被移动到 TempDB，并且在列的末尾附加了 12-14 个字节之间的内容。打开具有隔离级别（例如快照隔离）的乐观锁定可能会导致碎片化，并且您的填充因子将需要调整，因为现在行末尾有额外的数据，这可能会导致页面接近满而导致页面拆分，这将降低你的表现。如果您的 TempDB 未得到优化，那么速度将不会那么快。

所以我想一个清单是：

• - 您是否有足够的 IO/资源来处理行版本控制的形式？如果没有，您将增加开销。如果是这样，那么如果您经常读取数据而您经常锁定它以进行写入，您会注意到读取和写入之间的并发性有很好的改进（尽管写入仍会阻塞写入，读取将不再阻塞写入，反之亦然）
• - 您的代码是否容易出现死锁或您是否遇到过锁定？如果您没有遇到长锁或大量死锁，那么乐观锁的额外开销不会使事情更快，当然，在大多数情况下，我们在这里讨论的是毫秒。
• - 如果您的数据库很大（或在非常有限的硬件上）并且您的数据页接近满，取决于 RDBMS，您可能会导致主要页面拆分和数据碎片，因此请确保在打开它后考虑重新索引。

这些是我对此事的看法，愿意听取社区的更多意见。