主要内容 1.不同隔离级别下的乐观锁有区别吗?(可重复读和读已提交) 2.当前读和锁等待的必然联系 3.当前读有哪些? 4.当前读，总是读取已经提交完成的最新版本。

当前读和锁等待的必然联系

因为当前读必须要读最新版本,如果此时该行数据上有事物尚未提交,则当前事务必须等待锁,这样才能保证读取到最新的记录.

一个无法更新的现象

Q: 事务隔离级别是可重复读。现在，我要把所有“字段 c 和 id 值相等的行”的 c 值清零，但是却发现了一个“诡异”的、改不掉的情况

Q:可重复读 下 乐观锁 还会有效吗? // 工作中遇到疑问

我看leader把select和udpate放一个事务里，这个乐观锁有点尴尬。

如果是可重复读的隔离级别，那么对当前事务来说，只有version = version的情况啊，这个是横成立的。 即使其他事务对version进行了修改，这个事务也是看不到的吧?

A: 发现可重复读的情况下， 乐观锁也是没问题。因为update是当前读。乐观锁在可重复读下的使用

Q: 乐观锁在可重复读下的使用的过程?

// 附录1

以下是技术群讨论后,2021-05-26更新

update包含了当前读

群讨论

以下是技2021-08-11更新

业务中使用的乐观锁 TODO

Q:什么业务要加锁,加乐观锁 or 悲观锁

Q:乐观锁怎么加

Q:悲观锁怎么加

乐观锁在可重复读的隔离级别下会有问题

乐观锁在可重复读的隔离级别下,每次重试都是快照读,永远不会更新成功,很多请求一直重试,则会导致事务锁等待超时。

update操作是当前,会加行锁,导致修改同一行的数据锁等待,多等几次就超时了。

// 附录4

解决方案: 乐观锁需要配合读已提交的隔离级别才可以,这样是当前读,可以在最新版本的基础上进行更新,才会成功。

1.使用版本号实现乐观锁的不足 TODO

// 附录3

秒杀等高并发场景下,每个版本只能成功1个,也就是每次只能有1个人抢购成功。 比如有库存100个,每人买1个,那么单个用户最多需要重试99次才能买到,但是正常是用户只需要抢购1次,如果有库存就能成功。 而不是有库存但是版本号不对则不能成功.

TODO Q:什么场景是必须在正确的版本号基础上修改才可以.

Q:什么场景不依赖版本号,只依赖某些限制条件(如:库存),则可以修改.

2.使用条件限制实现乐观锁

比如,库存模型和份额+-

参考资料

1.08 | 事务到底是隔离的还是不隔离的？ 2.本机资料【169期】面试官：同学，分析一下MySQL_InnoDB的加锁过程吧-技术圈.pdf 3.使用mysql乐观锁解决并发问题 4.乐观锁加重试，并发更新数据库一条记录导致：Lock wait timeout exceeded