我了解乐观锁定和悲观锁定之间的区别。现在有人可以向我解释我什么时候会使用其中任何一个吗？
这个问题的答案是否会根据我是否使用存储过程来执行查询而改变？
但只是为了检查，乐观的意思是“阅读时不要锁定表格”，悲观的意思是“阅读时锁定表格”。
At any technique type conflicts should be detected and considered, with similar overhead for both materialized and non-materialized conflicts。
Optimistic Locking 是一种读取记录的策略，记下版本号（执行此操作的其他方法涉及日期、时间戳或校验和/哈希）并在写回记录之前检查版本是否未更改。当您写回记录时，您会过滤版本上的更新以确保它是原子的。 （即在您检查版本并将记录写入磁盘之间尚未更新）并一键更新版本。
如果记录是脏的（即与您的不同版本），您将中止事务并且用户可以重新启动它。
此策略最适用于大容量系统和三层架构，您不必为会话维护与数据库的连接。在这种情况下，客户端实际上无法维护数据库锁，因为连接是从池中获取的，并且您可能没有使用从一次访问到下一次访问的相同连接。
Pessimistic Locking 是您锁定记录以供您独占使用，直到您完成它为止。它比乐观锁定具有更好的完整性，但需要您小心应用程序设计以避免Deadlocks。要使用悲观锁定，您需要直接连接到数据库（通常在 two tier client server 应用程序中就是这种情况）或可以独立于连接使用的外部可用事务 ID。
在后一种情况下，您使用 TxID 打开事务，然后使用该 ID 重新连接。 DBMS 维护锁并允许您通过 TxID 选择会话备份。这就是使用两阶段提交协议（例如 XA 或 COM+ Transactions）的分布式事务的工作方式。
处理冲突时，您有两种选择：
您可以尝试避免冲突，这就是悲观锁定的作用。
或者，您可以允许冲突发生，但您需要在提交事务时检测到它，这就是乐观锁定所做的。
现在，让我们考虑以下丢失更新异常：
https://i.stack.imgur.com/vCagm.png
丢失更新异常可能发生在 Read Committed 隔离级别。
在上图中，我们可以看到 Alice 认为她可以从她的 account 中提取 40，但没有意识到 Bob 刚刚更改了账户余额，现在这个账户只剩下 20 了。
悲观锁定
悲观锁定通过在帐户上获取共享或读取锁定来实现此目标，因此防止 Bob 更改帐户。
https://i.stack.imgur.com/oybRy.png
在上图中，Alice 和 Bob 都将在两个用户都已读取的 account 表行上获得一个读取锁。当使用可重复读取或可序列化时，数据库会在 SQL Server 上获取这些锁。
因为 Alice 和 Bob 都读取了 PK 值为 1 的 account，所以在一个用户释放读取锁之前，他们都不能更改它。这是因为写操作需要获取写/独占锁，而共享/读锁防止写/独占锁。
只有在 Alice 提交了她的事务并且在 account 行上释放了读锁之后，Bob UPDATE 才会恢复并应用更改。在 Alice 释放读锁之前，Bob 的 UPDATE 会阻塞。
乐观锁定
乐观锁定允许发生冲突，但在应用 Alice 的 UPDATE 时检测到它，因为版本已更改。
https://i.stack.imgur.com/DEdlF.png
这一次，我们有一个额外的 version 列。每次执行 UPDATE 或 DELETE 时，version 列都会递增，它也用于 UPDATE 和 DELETE 语句的 WHERE 子句中。为此，我们需要在执行 UPDATE 或 DELETE 之前发出 SELECT 并读取当前的 version，否则，我们将不知道将哪个版本值传递给 WHERE 子句或递增。
应用程序级事务
关系数据库系统出现在 70 年代末 80 年代初，当时客户端通常会通过终端连接到大型机。这就是为什么我们仍然看到数据库系统定义诸如 SESSION 设置之类的术语。
现在，在互联网上，我们不再在同一个数据库事务的上下文中执行读写，ACID 已经不够用了。
例如，考虑以下用例：
https://i.stack.imgur.com/FCyHh.png
如果没有乐观锁定，即使数据库事务使用 Serializable，也无法捕获此丢失的更新。这是因为读取和写入是在不同的 HTTP 请求中执行的，因此是在不同的数据库事务中执行的。
因此，即使在使用包含用户思考时间的应用程序级事务时，乐观锁定也可以帮助您防止丢失更新。
结论
乐观锁定是一种非常有用的技术，即使在使用不太严格的隔离级别（如已提交读）或在后续数据库事务中执行读取和写入时，它也能正常工作。
乐观锁定的缺点是数据访问框架会在捕获 OptimisticLockException 时触发回滚，因此会丢失我们之前通过当前正在执行的事务完成的所有工作。
争用越多，冲突就越多，中止交易的机会就越大。回滚对数据库系统来说代价高昂，因为它需要恢复所有当前可能涉及表行和索引记录的未决更改。
因此，当冲突频繁发生时，悲观锁定可能更适合，因为它减少了回滚事务的机会。
当您不期望有很多冲突时，使用乐观锁定。进行正常操作的成本较低，但如果发生冲突，您将支付更高的价格来解决它，因为交易被中止。
当预计会发生冲突时，使用悲观锁定。违反同步的事务被简单地阻止。
要选择适当的锁定机制，您必须估计读取和写入的数量并相应地进行计划。
乐观假设在您阅读它时没有任何变化。
悲观主义假设某事会因此锁定它。
如果完全读取数据不是必需的，请使用乐观。您可能会得到奇怪的“脏”读 - 但它不太可能导致死锁等。
大多数 Web 应用程序都可以处理脏读——在极少数情况下，数据与下一次重新加载时的数据不完全一致。
对于精确的数据操作（如在许多金融交易中）使用悲观。准确读取数据至关重要，没有未显示的更改 - 额外的锁定开销是值得的。
哦，Microsoft SQL 服务器默认为页面锁定 - 基本上是您正在阅读的行和两边的一些。行锁定更准确但慢得多。通常值得将您的事务设置为已提交读或无锁，以避免在读取时出现死锁。
当悲观锁定将是更好的选择时，我会想到另一种情况。
对于乐观锁定，数据修改的每个参与者都必须同意使用这种锁定。但是如果有人修改数据而不关心版本列，这将破坏乐观锁定的整个想法。
基本上有两个最受欢迎的答案。 first one 基本上说
乐观需要一个三层架构，您不必为会话维护与数据库的连接，而悲观锁定是您锁定记录以供您独占使用，直到您完成它。它比乐观锁定具有更好的完整性，您需要直接连接到数据库。
乐观（版本控制）由于没有锁定而更快，但（悲观）锁定在争用高时表现更好，并且最好阻止工作而不是丢弃它并重新开始。
或者
当你有罕见的碰撞时，乐观锁定效果最好
As it is put 在此页面上。
我创建了我的答案来解释“保持连接”与“低碰撞”的关系。
要了解哪种策略最适合您，请不要考虑数据库的每秒事务数，而要考虑单个事务的持续时间。通常，您打开事务，执行操作并关闭事务。这是 ANSI 考虑的一个简短的经典事务，可以很好地摆脱锁定。但是，您如何实现多个客户同时预订相同房间/座位的订票系统？
您浏览报价，在表格中填写大量可用选项和当前价格。这需要很多时间，选项可能会过时，您开始填写表格并按下“我同意”按钮之间的所有价格都无效，因为您访问的数据没有锁定，并且其他更敏捷的人干扰了更改所有价格，您需要以新价格重新开始。
相反，您可以在阅读它们时锁定所有选项。这是悲观的情景。你明白为什么它很糟糕。您的系统可能会被一个简单地开始预订并吸烟的小丑搞垮。在他完成之前，没有人可以保留任何东西。您的现金流量降至零。这就是为什么在现实中使用乐观保留。那些磨磨蹭蹭的人不得不以更高的价格重新开始预订。
在这种乐观的方法中，您必须记录您读取的所有数据（如 mine Repeated Read 中）并使用您的数据版本到达提交点（我想以您在此报价中显示的价格购买股票，而不是当前价格）。此时，创建了 ANSI 事务，它锁定数据库，检查是否没有任何更改并提交/中止您的操作。 IMO，这是对 MVCC 的有效模拟，它也与 Optimistic CC 相关联，并且还假设您的事务在中止的情况下重新启动，即您将进行新的预订。这里的交易涉及人类用户的决策。
我远未理解如何手动实现 MVCC，但我认为带有重启选项的长时间运行的事务是理解该主题的关键。如果我在任何地方错了，请纠正我。我的回答是由 this Alex Kuznecov chapter 激发的。
在大多数情况下，乐观锁定更有效并提供更高的性能。在悲观锁定和乐观锁定之间进行选择时，请考虑以下几点：
如果有大量更新并且用户尝试同时更新数据的机会相对较高，则悲观锁定很有用。例如，如果每个操作一次可以更新大量记录（银行可能会在每个月底为每个帐户添加利息收入），并且两个应用程序同时运行此类操作，它们就会发生冲突.
悲观锁定也更适合包含经常更新的小表的应用程序。在这些所谓的热点的情况下，冲突的可能性如此之大，以至于乐观锁定浪费了回滚冲突事务的努力。
如果发生冲突的可能性非常低，乐观锁定很有用——记录很多但用户相对较少，或者更新很少且主要是读取类型的操作。
乐观锁定的一个用例是让您的应用程序使用数据库来允许您的一个线程/主机“声明”一项任务。这是一种对我来说经常派上用场的技术。
我能想到的最好的例子是使用数据库实现的任务队列，多个线程同时声明任务。如果任务的状态为'Available'、'Claimed'、'Completed'，则数据库查询可以说类似“Set status='Claimed' where status='Available'。如果多个线程尝试以这种方式更改状态，除了第一个线程之外的所有线程都会因为脏数据而失败。
请注意，这是一个仅涉及乐观锁定的用例。因此，作为说“当您不期望有很多冲突时使用乐观锁定”的替代方法，它也可以用于您期望发生冲突但只希望一个事务成功的地方。
上面已经说了很多关于乐观和悲观锁定的好话。需要考虑的重要一点如下：
在使用乐观锁时，我们需要注意应用程序将如何从这些故障中恢复。
特别是在异步消息驱动架构中，这可能导致消息处理乱序或更新丢失。
需要考虑故障情况。
在更实际的情况下，更新分布式系统时，数据库中的乐观锁定可能不足以提供分布式系统所有部分所需的一致性。
例如，在 AWS 上构建的应用程序中，通常在 DB（例如 DynamoDB）和存储（例如 S3）中都有数据。如果更新涉及 DynamoDB 和 S3，DynamoDB 中的乐观锁定仍可能使 S3 中的数据不一致。在这种情况下，使用 DynamoDB 中的悲观锁可能更安全，直到 S3 更新完成。事实上，AWS 为此提供了一个 locking library。
乐观锁定和悲观锁定是在数据库中锁定数据的两种模型。
乐观锁定：仅在将更改提交到数据库时才锁定记录。
悲观锁定：记录在编辑时被锁定。
注意：在这两种数据锁定模型中，锁在更改提交到数据库后被释放。
