目录
事务的隔离性由这章讲述的锁来实现。
一、概述
锁是计算机协调多个进程或线程并发访问某一资源的机制。在程序开发中会存在多线程同步的问题，当多个线程并发访问某个数据的时候，尤其是针对一些敏感的数据（比如订单、金额等），我们就需要保证这个数据在任何时刻最多只有一个线程在访问，保证数据的完整性和一致性。在开发过程中加锁是为了保证数据的一致性，这个思想在数据库领域中同样很重要。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。为保证数据的一致性，需要对
并发操作进行控制，因此产生了锁。同时锁机制也为实现MySQL的各个隔离级别提供了保证。锁冲突也是影响数据库并发访问性能的一个重要因素。所以锁对数据库而言显得尤其重要，也更加复杂
二、MySQL并发事务访问相同记录
并发事务访问相同记录的情况大致可以划分为3种：
1、读-读情况
读-读情况，即并发事务相继读取相同的记录。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。
2、写-写情况
小结几种说法：
不加锁
意思就是不需要在内存中生成对应的
锁结构，可以直接执行操作。获取锁成功，或者加锁成功
意思就是在内存中生成了对应的
锁结构，而且锁结构的is_waiting属性为false，也就是事务 可以继续执行操作。获取锁失败，或者加锁失败，或者没有获取到锁
意思就是在内存中生成了对应的锁结构，不过锁结构的
is_waiting属性为true，也就是事务 需要等待，不可以继续执行操作。
3、读-写或写-读情况
读-写或写-读，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生脏读、不可重复读、幻读的问题。各个数据库厂商对
SQL标准的支持都可能不一样。比如MySQL在REPEATABLE READ隔离级别上就已经解决了幻读问题
4、并发问题的解决方案
小结对比发现：
采用
MVCC方式的话，读-写操作彼此并不冲突，性能更高。采用
加锁方式的话，读-写操作彼此需要排队执行，影响性能。一般情况下我们当然愿意采用
MVCC来解决读-写操作并发执行的问题，但是业务在某些特殊情况下，要求必须采用加锁的方式执行。下面就讲解下MySQL中不同类别的锁
三、锁的不同角度分类
锁的分类图，如下：
1、从数据操作的类型划分：读锁、写锁
- 读锁 ：也称为 共享锁 、英文用 S 表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。
- 写锁 ：也称为 排他锁 、英文用 X 表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。
需要注意的是对于 InnoDB 引擎来说，读锁和写锁可以加在表上，也可以加在行上。
2、从数据操作的粒度划分：表级锁、页级锁、行锁
1. 表锁（Table Lock）
① 表级别的S锁、X锁
② 意向锁 （intention lock）
③ 自增锁（AUTO-INC锁）
④ 元数据锁（MDL锁）
2.InnoDB中的行锁
① 记录锁（Record Locks）
② 间隙锁（Gap Locks）
③ 临键锁（Next-Key Locks）
④ 插入意向锁（Insert Intention Locks）
3. 页锁
3、从对待锁的态度划分:乐观锁、悲观锁
从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式 。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的设计思想 。
1. 悲观锁（Pessimistic Locking）
- 悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。
- 悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。
2. 乐观锁（Optimistic Locking）
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是 不采用数据库自身的锁机制，而是通过程序来实现 。在程序上，我们可以采用
版本号机制或者CAS机制实现。 乐观锁适用于多读的应用类型，这样可以提高吞吐量 。在Java中java.util.concurrent.atomic包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。
1.乐观锁的版本号机制
在表中设计一个
版本字段 version，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行UPDATE ... SET version=version+1 WHERE version=version。此时如果已经有事务对这条数据进行了更改，修改就不会成功。2. 乐观锁的时间戳机制
时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行 比较，如果两者一致则更新成功，否则就是版本冲突。
你能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳（版本号或 者时间戳），从而证明当前拿到的数据是否最新。
3.两种锁的适用场景
从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：
乐观锁适合读操作多的场景，相对来说写的操作比较少。它的优点在于程序实现，不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
悲观锁适合写操作多的场景，因为写的操作具有排它性。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止读 - 写和写 - 写的冲突
4、按加锁的方式划分：显式锁、隐式锁
1. 隐式锁
隐式锁的逻辑过程如下：
A. InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。
B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将 隐式锁 转换为 显式锁 (就是为该事务添加一个锁)。
C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。
D. 等待加锁成功，被唤醒，或者超时。
E. 写数据，并将自己的trx_id写入trx_id字段。
2. 显式锁
5、其它锁之：全局锁
全局锁就是对 整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用 场景 是：做 全库逻辑备份 。
全局锁的命令：Flush tables with read lock
6、其它锁之：死锁
四、锁的内存结构
InnoDB 存储引擎中的 锁结构 如下：
结构解析：
五、锁监控
六、附录
间隙锁加锁规则（共11个案例）
---见课件笔记
高级篇笔记PDF自取
链接：https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333
提取码：3333
742
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
