mysql的乐观锁真的有用吗

Question

个人理解

个人认为，乐观锁并不是真正的锁，更像一种数据处理流程。它并没有提供阻塞服务，在自己处理数据的时候，允许别人对源数据进行增删改查的数据操作。只是在，最后更新时候，做个判断，看看数据还是不是之前的那个数据。
如果数据没变，数据正常更新就完事了。但是，如果此时数据发生改变的时候，那么问题是不是就来了呢？

解决与疑问

• 解决方式一：直接报错，告诉客户你错了。
  疑问：不太好吧？那客户岂不是一脸懵逼？
• 解决方式二：如果有事务加持的时候，让事务回滚。
  疑问：那数据操作咋办？还要不要操作了？
• 解决方式三：放在do...while循环中，一次更新不成功，就重新获取，重新计算，直到成功更新。
  疑问：算是个比较良心的解决方法。但是这样的代码构建就复杂了，不太利于后期维护。如果，访问量大的情况下，这种的效率更低。

你们都是怎么使用乐观锁的？

Answer 1

其实，这是一个权衡的问题。如下：

• 乐观锁

SELECT * FROM test WHERE id=1;
UPDATE SET data='xxx',version=version+1 WHERE id=1 AND version=0;

• 悲观锁

SELECT * FROM test WHERE id=1 FOR UPDATE;
UPDATE SET data='xxx' WHERE id=1;

乐观锁只在更新的时候加锁，而悲观锁在查询的时候就开始加锁，显然乐观锁的加锁范围更少，而悲观锁的加锁范围更大。一般来说，加锁的范围越小并发度就越大。

乐观锁和悲观锁其实是做事情的两种方法。一种是预防（悲观锁），一种是治疗（乐观锁）。如果不好的事情频繁发生，显然应该使用预防的方法，而如果不好的事情只是偶尔发生，那么就应该使用治疗的方法。

很容易产生的疑问是： 我想让系统系统并发度大，你却让我在并发度小的时候使用乐观锁，那系统并发度很小，我直接使用悲观锁了，为什么还要用乐观锁 ？
其实关键点在于并发度这个词上，某一具体逻辑的并发度小 ＝> 使用乐观锁 ＝> 减少了锁范围 ＝> 提升了系统整体的并发能力。

Answer 2

乐观锁如果数据更新失败进行重试retry

Answer 3

如果，访问量大的情况下，这种的效率更低。

本来乐观锁就是在访问量不大的情况下的优化手段...如果乐观锁在任何场景下效率都可以，那悲观锁还有存在的必要嘛？