数据库锁机制

一、什么是锁机制，为什么要用锁机制

我们可以通过一个很简单的比喻来理解事务的锁机制。比如同一个办公室的同事们，都想使用打印机打印文件，如果不加以控制，可能出现两个人同时打印不同的内容在一个文件里，就会引起内容混乱。于是，我们就引入了锁的概念，当有并发的多个事务同时操作同一份数据时，只有“抢到”了锁的事务，才能真正去操作数据，使得数据的安全性得到保证。

锁保证并发的多个事务同一时间只有一个能运行，会一定程度上降低程序的运行效率，但是能大大提升数据的安全性。

二、数据库锁的分类

1、按粒度分

数据库的锁按粒度分为行级锁,表级锁,页级锁

⾏级锁 ⾏级锁是Mysql中锁定粒度最细的⼀种锁，表示只针对当前操作的⾏进⾏加锁。⾏级锁能⼤⼤减少数据库操作的冲突。其加锁粒度最⼩，但加锁的开销也最⼤。⾏级锁分为共享锁和排他锁。

特点：开销⼤，加锁慢；会出现死锁；锁定粒度最⼩，发⽣锁冲突的概率最低，并发度也最⾼。

由于数据库的库和表都是事先建好的，所以我们针对数据库的操作一般都是针对记录。而对记录进行的四种操作（增删改查），我们可以分为两类，增删改属于读操作，而查询属于写操作。

写操作默认就会加锁，且加的是互斥锁，很容易理解，在进行写行为的时候一定是必须“排他”的。读操作默认不受任何锁影响，但是互斥锁和共享锁都可以加。

读操作加互斥锁 for update;

读操作加共享锁 lock in share mode;

提示：关于共享锁和互斥锁，我们将在下一小节更详细地讲述

行级锁锁的是索引,命中索引以后才会锁行,如果没有命中索引,会把整张表都锁起来。命中主键索引就锁定这条语句命中的主键索引,命中辅助索引就会先锁定这条辅助索引,再锁定相关的主键索引，考虑到性能，innodb默认支持行级锁，但是只有在命中索引的情况下才锁行，

否则锁住所有行，本质还是行锁,但是此刻相当于锁表了

行级锁有三种算法：

1、Record lock
2、Gap lock
3、Next-key lock

其中 Next-key lock 为MySQL默认的锁机制，相当于另外两种锁的功能的整合，并能够解决幻读问题。

提示：在RR事务隔离机制下，才会锁间隙，而RR机制是mysql的默认事务隔离机制。所以，在默认情况下，其实innodb存储引擎锁的是行以及间隙.

我们可以用一个实验来验证上述关于行锁的结论

实验

	事务一	事务二
步骤1	start transaction;	– 开启事务start transaction;
步骤2		– 加排他锁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之间的值都会被锁定
步骤3	– 下述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);
步骤4	– 提交一下事务，不要影响下一次实验commit;	– 提交一下事务，不要影响下一次实验commit;

2、按级别分

数据库的锁按级别分为共享锁，排他锁，共享锁，又被称作读锁，s锁，含义是多个事务共享同一把锁，其中每个事务都能访问到数据，但是没有办法进行修改。

注意：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁或不加锁（在其他事务里一定不能再加排他锁，但是在事务T自己里面是可以加的）

排他锁，又被称作互斥锁，写锁，x锁，含义是如果有一个事务获取了一个数据的排他锁，那么其它的事务都无法再次获得该数据的任何锁了，但是排他锁支持文件读取，修改和写入。

3、按使用方式分

数据库的锁按使用方式分为悲观锁、乐观锁

悲观锁（Pessimistic Locking），顾名思义指的是对外界将要进行的数据修改操作持悲观态度，因此，在整个数据处理过程中，将数据处于锁定状态。现在由于互联网的高并发架构，即使加上悲观锁也无法保证数据不被外界修改，因此不推荐使用。

乐观锁（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，就会互相锁住，产生死锁现象，而且这种情况非常隐蔽，较难排查。