一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第24天，点击查看活动详情
从对待锁的态度来划分为：悲观锁和乐观锁
悲观锁和乐观锁实际上是前辈在使用锁的时候根据锁的特性来取的一种概念性名称，实际上是一种概念，mysql引擎实际上并不存在这两种锁。
1. 悲观锁 (Pessimistic Locking)
悲观锁顾名思义就是态度很悲观，对别人很自私总是觉得有别的锁会要图谋不轨想要抢走当前锁的资源，悲观锁是由数据库的锁机制实现的，保证了锁的排他性，也就是独占锁。
如果掘友们平时对悲观锁有过了解就知道，实际上在我们的SQL最后加上关键词：for update即可达到悲观锁的实现，举个例子，比如当前有一个促销活动商家并夕夕推出一个活动，小米11手机只需要999元即可带回家总限量10台每人限购一台，此时张三先来到了店里准备抢购一台，但是在准备过程中突然外面一下子来了几百人准备要进来抢购，此时张三如果是持有悲观锁的思想，那么张三就反手将店里的大门给关上了，直到直接购买完成才将大门打开，就是为了防止其他人来抢购手机导致直接抢购失败，那么行为就是悲观锁。（ps：形容悲观锁的意思是这样子，现实中可能会被打，大家理解一下哈哈）
2.乐观锁Optimistic Locking
乐观锁顾名思义就是态度很乐观，对别人很好总是觉得别的锁不会图谋不轨来抢占自己的资源，乐观锁不是数据库层面锁的机制实现的，是由我们业务代码层面来实现的，但是会在数据库表新增一个字段版本号：version用于对比当前数据是否最新，如果是则可以更新，也就是在更新之前会先查询一下当前记录的version字段值，然后在更新数据的条件多加一个version = version（查询出来的） + 1，当然每次更新完都必须将version字段更新。
那么这种思想带入到上面的例子张三我们再来看一下会发生什么情况，张三先来到了店里准备抢购一台，但是在准备过程中突然外面一下子来了几百人准备要进来抢购，此时张三持有乐观锁的思想，并没有做任何措施，而是自己老老实实的在准备抢购，如果顺利因为张三是先进来的有一定的时间优势可以顺利的抢购到手机，但是如果在抢购的过程中被外面从进来的人群挤到外面去了导致张三抢购手机失败，那么即使张三是先来的也最终抢购失败，所以乐观锁不能保证即使事务先开启就一定能执行成功，也就是说虽然乐观锁提高了吞吐量，但是事务之间的竞争是非常大的。
总结
悲观锁使用场景：对写数据操作多的情况有直接的效果，但是对于读取数据多的操作本身就不会影响，所以不适用悲观锁。
乐观锁的使用场景：乐观锁就相反，对于读取数据多的时候那么使用效果显著，因为只要不修改数据那么就不会造成事务失败。
