MySQL中的锁

共享锁

共享锁也成为读锁，针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。

• 通过下面命令加共享锁

SELECT...LOCK IN SHARE MODE
#或
SELECT...FOR SHARE;#(8.0新增语法)

排他锁

排他锁也叫写锁，当一个事务对一份数据执行写入，即加上排他锁后，其他事务对同一份数据进行读写操作会阻塞，直到前一个事务提交。

• 通过下面的命令加排他锁

SELECT ... FOR UPDATE;

• DELETE、UPDATE、INSERT等操作也相当于加排他锁

共享锁和排他锁是否会发生阻塞如下图所示：

	共享锁	排他锁
共享锁	不阻塞	阻塞
排他锁	阻塞	阻塞

行级锁

行级锁是锁住行，粒度小，性能较高，但是行级锁只在存储引擎层实现，行级锁分为3种，记录锁、间隙锁和临键锁。

假如下面的一个表test_lock:

id	a	b
0	0	0
4	4	4
8	8	8
16	16	16
32	32	32

• id是主键索引
• a是普通索引
• b是普通列

记录锁 （Record Locks）

记录锁是仅仅锁住一条记录，锁的粒度最小。

什么时候会加记录锁？

当用唯一索引进行等职查询时，且查询的记录是存在的时候，会加记录锁。

会话1	会话2	会话3
begin;select * from test_lock where id = 16 for update;
	update test_lock set a = 100 where id = 16;(阻塞)
		insert into test_lock value(9, 9, 9);(正常)

• 会话1对id=16记录加了行锁
• 会话2阻塞，无法对这条记录进行修改操作
• 会话3正常插入

间隙锁（Gap Locks）

"幻读"的问题，事务期间其他事务添加一条数据，再次读取突然多出一条记录。为了解决这样的问题，是不是可以对一段区间的数据加锁，加上锁以后，其他事务添加数据时必须阻塞。像这样的锁就叫做间隙锁，即锁定一个区间，左开右开。

什么情况会加 间隙锁 ？

• 在用唯一索引进行等值查询时，当查询记录不存在时，会加间隙锁。

select * from test_lock where id = 10 for update;

id=10位于8到16区间，由于10这条记录不存在，所以加的间隙锁，锁定(8, 16)的区间。

• 唯一锁引使用范围查询的时候，会加间歇锁。

select * from test_lock where id <10 and id> 8 for update;

id <10 and id> 8是一个范围查询，会锁定范围（8，16）。

• 普通索引等值查询时，如果记录存在，会额外添加一个间隙锁。

select * from test_lock where a = 8 for update;

由于a=8记录存在，会对范围（4，8]添加临键锁,这个后面会提到，同时额外向下遍历到第一个不符合条件的值才能停止，因此间隙锁的范围是(8,16)。

• 通索引等值查询时，如果记录不存在，会加一个间隙锁。

select * from test_lock where a = 10 for update;

此种情况锁定的范围为(8,16)

临键锁（Next-Key Locks）

如果想要同时集合上面的记录锁和间隙锁，也就是既想锁住某条记录，又想阻止其他事务在该记录前边的间隙插入新记录，所以InnoDB就提出了临键锁（Next-Key Locks），默认锁定的范围是左开右闭。InnoDB存储引擎默认的锁单位就是临键锁（Next-Key Locks)，怎么理解呢？

也就是锁加锁都是按照临键锁加锁，但是会根据一定的规律退化为记录锁和间隙锁。具体规律如下：

唯一索引等值查询：

• 当查询的记录是存在的，临键锁会退化成「记录锁」。
• 当查询的记录是不存在的，临键锁 会退化成「间隙锁」。

非唯一索引等值查询：

• 当查询的记录存在时，除了会加 临键锁外，还额外加间隙锁，也就是会加两把锁。
• 当查询的记录不存在时，只会加 临键锁，然后会退化为间隙锁，也就是只会加一把锁。

InnoDB存储引擎中，如果一个表查询或者更新没有走索引，这时候还会创建行级锁吗？ 答案是不会，这时候会升级为表级锁。

页级锁

页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。因此，采取了折衷的页级锁，一次锁定相邻的一组记录。BDB (BerkeleyDB)存储引擎 支持页级锁。

特点

• 开销和加锁时间界于表锁和行锁之间
• 会出现死锁
• 锁定粒度界于表锁和行锁之间，并发度一般

表级锁

表锁会锁定整张表，它是MySQL中最基本的锁策略，并不依赖于存储引擎，表锁是开销最小的策略。因为表级锁一次会将整个表锁定，所以可以很好的避免死锁问题。但是表锁的并发度很差，那表锁都有哪几种呢？

表级别的S锁、X锁

• LOCK TABLES t READ ：InnoDB存储引擎会对表 t 加表级别的 S锁 。
• LOCK TABLES t WRITE：InnoDB存储引擎会对表 t 加表级别的 X锁 。

意向锁

意向锁也是一种表锁，表示某个事务正在锁定一行或者将要锁定一行，表明一个意图。它不与行级锁冲突。那它究竟有啥作用？

意向锁是在当事务加表锁时发挥作用。比如一个事务想要对表加排他锁，如果没有意向锁的话，那么该事务在加锁前需要判断当前表的每一行是否已经加了锁，如果表很大，遍历每行进行判断需要耗费大量的时间。如果使用意向锁的话，那么加表锁前，只需要判断当前表是否有意向锁即可，这样加快了对表锁的处理速度。

意向锁分为两种：

• 意向共享锁（intention shared lock, IS）：事务有意向对表中的某些行加共享锁（S锁）
• 意向排他锁（intention exclusive lock, IX）：事务有意向对表中的某些行加排他锁（X锁）

自增锁（AUTO-INC LOCK）

我们都知道在使用创建表的时候有自增主键AUTO_INCREMENT属性，那它是怎么实现自增的呢？

AUTO-INC锁是当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁，在执行插入语句时就在表级别加一个AUTO-INC锁，然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值，在该语句执行结束后，再把AUTO-INC锁释放掉。

元数据锁（MDL锁）

元数据锁可以用来保证读写的正确性。比如，如果一个查询正在遍历一个表中的数据而执行期间另一个线程对这个 表结构做变更 ，增加了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。

• 当对一个表做增删改查操作的时候，加 MDL读锁；
• 当要对表做结构变更操作的时候，加 MDL 写锁。

MDL读锁和读锁之间可以共享兼容，读锁和写锁之间不兼容，会互相阻塞。

全局锁

全局锁就是对 整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后 其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结 构等）和更新类事务的提交语句。

全局锁的典型使用场是做全库逻辑备份。

## 全局锁命令
flush tables with read lock

悲观锁

悲观锁是总以最坏的情况假设，比如操作一条数据，总认为也有其他线程要拿这条数据，那就给这条数据上排他锁，让其他事务或者线程阻塞，类似于Java中 synchronized 和 ReentrantLock 等独占锁的思想。

适用场景：

悲观锁适写操作多的场景，因为写的操作具有 排它性 。采用悲观锁的方式，可以在数据库层 面阻止其他事务对该数据的操作权限，防止读 - 写和写 - 写的冲突。

实现思路：

以秒杀商品为例，为了防止超卖，需要加锁。

#第1步： for update 方式查出商品库存
select quantity from items where id 1001 for update;
#第2步：如果库存大于0，则根据商品信息生产订单
insert into orders (item_id)values(1001);
#第3步：修改商品的库存，um表示购买数量
update items set quantity quantity-num where id 1001;

select····for update是MySQL中悲观锁。此时在items表中，id为1001的那条数据就被我们锁定了，其他的要执行select quantity from items where id=1001 for update;语句的事务必须等本次事务提交之后才能执行。这样我们可以保证每次事务能拿到最新的库存数量，从而不会超卖，但是这样的性能很差。

乐观锁

乐观锁认为一个事务发生并发的概率很小，就不加通过数据库加锁实现，因为加锁性能比较差，而是通过程序实现，那如何数据没有被其他事务修改了呢？会在更新数据的时候判断数据的版本或者时间戳是否发生变化。

实现思路：

版本号机制实现乐观锁

• 数据表中新增一个version字段
• 更新前读取出version字段
• 进行业务逻辑操作，更新数据， UPDATE ... SET version=version+1 WHERE version=version，版本+1
• 如果有其他线程更新了数据，那么上面的修改不成功，返回值为0，表示已经被人更新了，我们可以根据0去做业务操作

时间戳机制实现乐观锁

时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行 比较，如果两者一致则更新成功，否则就是版本冲突。

适用场景：

乐观锁适合读操作多的场景，相对来说写的操作比较少。它的优点在于 程序实现 ，不存在死锁问题。