【一】什么是锁机制
- 我们可以通过一个很简单的比喻来理解事务的锁机制。
- 比如同一个办公室的同事们
- 都想使用打印机打印文件
- 如果不加以控制
- 可能出现两个人同时打印不同的内容在一个文件里
- 就会引起内容混乱。
- 于是，我们就引入了锁的概念
- 当有并发的多个事务同时操作同一份数据时
- 只有“抢到”了锁的事务
- 才能真正去操作数据
- 使得数据的安全性得到保证。
- 都想使用打印机打印文件
【二】为什么要用锁机制
- 锁保证并发的多个事务同一时间只有一个能运行
- 会一定程度上降低程序的运行效率
- 但是能大大提升数据的安全性。
【三】数据库锁的分类
【1】按粒度分
- 数据库的锁按粒度分为
- 行级锁
- 表级锁
- 页级锁
（1）什么是⾏级锁
-
⾏级锁是Mysql中锁定粒度最细的⼀种锁
- 表示只针对当前操作的⾏进⾏加锁。
-
⾏级锁能⼤⼤减少数据库操作的冲突。
- 其加锁粒度最⼩，但加锁的开销也最⼤。
-
⾏级锁分为共享锁和排他锁。
（2）⾏级锁的特点
- 开销⼤，加锁慢；
- 会出现死锁；
- 锁定粒度最⼩，发⽣锁冲突的概率最低，并发度也最⾼
（3）⾏级锁解释
-
由于数据库的库和表都是事先建好的
- 所以我们针对数据库的操作一般都是针对记录。
- 而对记录进行的四种操作（增删改查）
- 我们可以分为两类
- 增删改属于读操作
- 而查询属于写操作。
-
写操作默认就会加锁，且加的是互斥锁
- 很容易理解，在进行写行为的时候一定是必须“排他”的。
- 读操作默认不受任何锁影响
- 但是互斥锁和共享锁都可以加。
-
读操作加互斥锁 for update;
-
读操作加共享锁 lock in share mode;
提示：关于共享锁和互斥锁，我们将在下一小节更详细地讲述
（4）行级锁锁的是索引
- 行级锁锁的是索引
- 命中索引以后才会锁行
- 如果没有命中索引
- 会把整张表都锁起来。
- 命中主键索引就锁定这条语句命中的主键索引
- 命中辅助索引就会先锁定这条辅助索引
- 再锁定相关的主键索引
- 考虑到性能，innodb默认支持行级锁
- 但是只有在命中索引的情况下才锁行，
- 否则锁住所有行
- 本质还是行锁
- 但是此刻相当于锁表了
（5）行级锁的三种算法
-
1、Record lock
-
2、Gap lock
-
3、Next-key lock
-
其中 Next-key lock 为MySQL默认的锁机制
- 相当于另外两种锁的功能的整合
- 并能够解决幻读问题。
-
提示：
- 在RR事务隔离机制下，才会锁间隙
- 而RR机制是mysql的默认事务隔离机制。
- 所以，在默认情况下，其实innodb存储引擎锁的是行以及间隙.
-
我们可以用一个实验来验证上述关于行锁的结论
（6）实验
| 事务一 | 事务二 |
|---|---|
| start transaction; | 开启事务start transaction; |
| -- 加排他锁select from t1 where id=7 for update; -- 须知-- 1、上述语句命中了索引，所以加的是行锁-- 2、InnoDB对于行的查询都是采用了Next-Key Lock的算法，锁定的不是单个值，而是一个范围（GAP）表记录的索引值为1，5，7，11，其记录的GAP区间如下：（-∞,1]，(1,5]，(5,7]，(7,11]，(11,+∞）因为记录行默认就是按照主键自增的，所以是一个左开右闭的区间其中上述查询条件id=7处于区间(5,7]中，所以Next-Key lock会锁定该区间的记录，但是还没完-- 3、*InnoDB存储引擎还会对辅助索引下一个键值加上gap lock**。区间(5,7]的下一个Gap是(7,11],所以(7,11]也会被锁定综上所述，最终确定5-11之间的值都会被锁定 | |
| -- 下述sql全都会阻塞在原地insert t1 values(5);insert t1 values(6);insert t1 values(7);insert t1 values(8);insert t1 values(9);insert t1 values(10); -- 下述等sql均不会阻塞insert t1 values(11); insert t1 values(1); insert t1 values(2);insert t1 values(3);insert t1 values(4); | |
| -- 提交一下事务，不要影响下一次实验commit; | -- 提交一下事务，不要影响下一次实验commit; |
【2】按级别分
-
数据库的锁按级别分为
- 共享锁，排他锁，共享锁
- 又被称作读锁，s锁
- 含义是多个事务共享同一把锁
- 其中每个事务都能访问到数据
- 但是没有办法进行修改。
-
注意：
- 如果事务T对数据A加上共享锁后
- 则其他事务只能对A再加共享锁或不加锁（在其他事务里一定不能再加排他锁
- 但是在事务T自己里面是可以加的）
-
排他锁又被称作互斥锁，写锁，x锁
- 含义是如果有一个事务获取了一个数据的排他锁
- 那么其它的事务都无法再次获得该数据的任何锁了
- 但是排他锁支持文件读取，修改和写入。
【3】按使用方式分
- 数据库的锁按使用方式分为
- 悲观锁、乐观锁
（1）悲观锁（Pessimistic Locking）
- 顾名思义指的是对外界将要进行的数据修改操作持悲观态度
- 因此，在整个数据处理过程中，将数据处于锁定状态。
- 现在由于互联网的高并发架构，即使加上悲观锁也无法保证数据不被外界修改，因此不推荐使用。
（2）乐观锁（Optimistic Locking）
- 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突
- 所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测
- 如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。
- 通常乐观锁的实现是在表中加一个字段（可能是时间戳或版本号）
- 在写入的时候会查询一下版本号
- 如果版本号没有改变，就写入数据库并同时改变版本号。
- 从本质上来说，乐观锁并没有加锁
- 所以效率会大大提升
- 但也有一定的缺陷，就是可能导致一部分任务的写入失败。
【四】死锁问题
- 我们举一个例子来形象的说明死锁这个概念。
- 比如你和你的邻居同时被锁在了屋子里
- 然而你有你邻居的钥匙
- 你的邻居也有你的钥匙
- 你们互相可以打开对方的房门
- 但是却都被锁在了各自的屋子里
- 这就是一个简单的死锁现象
【1】第一种情况的死锁
| 事务1 | 事务2 |
|---|---|
| begin | begin |
| select * from t1 where id=6 for update; | delete from t1 where id=3; |
| update t1 set age=18 where id=3; | delete from t1 where id=6; -- 阻塞 |
- 第一种死锁情况非常好理解，也是最常见的死锁
- 每个事务执行两条SQL，分别持有了一把锁
- 然后加另一把锁，产生死锁。
- 大多数死锁问题
- innodb存储引擎都会发现并抛出异常
- 但是有一种死锁问题极其隐蔽。
【2】第二种情况的死锁
- 与上一种死锁情况不同的是
- 这种死锁现象必须是两个事务同时运行的情况下才可能发生。
- 前面我们提到过，聚集索引对应的是一整行数据记录。
- 当事务1根据一定的过滤条件
- 筛选出两条辅助索引时
- 根据索引的有序性
- 在锁完辅助索引后锁主键索引时
- 先锁主键1对应的记录再锁主键2。
- 如果在此同时
- 事务2通过别的辅助索引同样访问到了这两条数据
- 但顺序却是先锁主键2再锁主键1
- 就会互相锁住
- 产生死锁现象
- 而且这种情况非常隐蔽，较难排查。