数据库面试知识点（六）数据库锁

一、锁的种类

（一）悲观锁（Pessimistic Lock）:

悲观锁特点: 先获取锁，再进行业务操作。

即 “悲观” 的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的 “一锁二查三更新” 即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的 select … for update 操作来实现悲观锁。当数据库执行 select for update 时会获取被 select 中的数据行的行锁，因此其他并发执行的 select for update 如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update 获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。

补充：
不同的数据库对 select for update 的实现和支持都是有所区别的，

oracle 支持 select for update no wait，表示如果拿不到锁立刻报错，而不是等待，MySQL 就没有 no wait 这个选项。
MySQL 还有个问题是 select for update 语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。因此如果在 MySQL 中用悲观锁务必要确定走了索引，而不是全表扫描。

（二）乐观锁（Optimistic Lock）:

1.乐观锁，也叫乐观并发控制，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，那么当前正在提交的事务会进行回滚。

2.乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即 “乐观” 的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。

乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。

3.一般的做法是 在需要锁的数据上增加一个版本号，或者时间戳，

实现方式举例如下：

乐观锁（给表加一个版本号字段） 这个并不是乐观锁的定义，给表加版本号，是数据库实现乐观锁的一种方式。

SELECT data AS old_data, version AS old_version FROM …;
根据获取的数据进行业务操作，得到 new_data 和 new_version
UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {

// 乐观锁获取成功，操作完成

} else {

// 乐观锁获取失败，回滚并重试

}

注意：

• 乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能
• 乐观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方。

总结：
悲观锁和乐观锁是数据库用来保证数据并发安全防止更新丢失的两种方法，例子在 select … for update 前加个事务就可以防止更新丢失。悲观锁和乐观锁大部分场景下差异不大，一些独特场景下有一些差别，一般我们可以从如下几个方面来判断。

• 响应速度： 如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁。’

• 冲突频率： 如果冲突频率非常高，建议采用悲观锁，保证成功率，如果冲突频率大，乐观锁会需要多次重试才能成功，代价比较大。

• 重试代价： 如果重试代价大，建议采用悲观锁。

二、锁的具体种类

（一）按范围（行级、页级、表级）划分，悲观锁可以分为：

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

（二）按使用性质划分，悲观锁分为：

1.共享锁（Share Lock）

S 锁，也叫读锁，用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。

2.排他锁（Exclusive Lock）

X 锁，也叫写锁，表示对数据进行写操作。如果一个事务对对象加了排他锁，其他事务就不能再给它加任何锁了。

（三）死锁

1.死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等竺的进程称为死锁进程。

表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的 InnoDB。

死锁的关键在于：两个 (或以上) 的 Session 加锁的顺序不一致。

那么对应的解决死锁问题的关键就是：让不同的 session 加锁有次序。

2.死锁的解决办法？

• 查出的线程杀死 kill
  SELECT trx_MySQL_thread_id FROM information_schema.INNODB_TRX;

• 设置锁的超时时间
  Innodb 行锁的等待时间，单位秒。可在会话级别设置，RDS 实例该参数的默认值为 50（秒）。

• 指定获取锁的顺序

【Java 面试那点事】

这里致力于分享 Java 面试路上的各种知识，无论是技术还是经验，你需要的这里都有！

这里可以让你【快速了解 Java 相关知识】，并且【短时间在面试方面有跨越式提升】

面试路上，你不孤单！