锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是 Mysql 在服务器层和存储引擎层的的并发控制。

加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否是否已解除、释放锁等。

不少人在开发的时候，应该很少会注意到这些锁的问题，也很少会给程序加锁(除了库存这些对数量准确性要求极高的情况下)，即使我们不会这些锁知识，我们的程序在一般情况下还是可以跑得好好的。因为数据库隐式帮我们加了这些锁了，只有在某些特定的场景下我们才需要手动加锁。

对于UPDATE、DELETE、INSERT语句，InnoDB 会自动给涉及数据集加排他锁（X) 。而 MyISAM 在执行查询语句 SELECT 前，会自动给涉及的所有表加读锁，在执行UPDATE、DELETE、INSERT操作前，会自动给涉及的表加写锁，这个过程并不需要我们去手动操作。

那么在特定情况下，我们该如何去加锁呢？下面咱们来认真的看看。

看上图就知道 MySQL 锁可以按使用方式分为：乐观锁与悲观锁。按粒度分可以分为表级锁，行级锁，页级锁。

• 共享锁与排他锁

共享锁（读锁）：其他事务可以读，但不能写。 排他锁（写锁） ：其他事务不能读取，也不能写。

• 粒度锁

MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现：

MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

表锁

从锁的粒度，我们可以分成两大类：

表锁: 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突概率高，并发度最低。

这些存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。

表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如 Web 应用

行锁: 开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高 不同的存储引擎支持的锁粒度是不一样的。

其特点为：

1. 最大程度的支持并发，同时也带来了最大的锁开销。
2. 在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。
3. 行级锁只在存储引擎层实现，而 Mysql 服务器层没有实现。行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统

---

• InnoDB 行锁和表锁都支持、MyISAM 只支持表锁。

• InnoDB 只有通过索引条件检索数据才使用行级锁，否则，InnoDB 使用表锁。也就是说，InnoDB 的行锁是基于索引的。

表锁下又分为两种模式： 表读锁（Table Read Lock）&& 表写锁（Table Write Lock）

• 表共享读锁 （Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
• 表独占写锁 （Table Write Lock）：会阻塞其他用户对同一表的读和写操作；

从下图可以清晰看到，在表读锁和表写锁的环境下：读读不阻塞，读写阻塞，写写阻塞！

读读不阻塞： 当前用户在读数据，其他的用户也在读数据，不会加锁

读写阻塞： 当前用户在读数据，其他的用户不能修改当前用户读的数据，会加锁！

写写阻塞： 当前用户在修改数据，其他的用户不能修改当前用户正在修改的数据，会加锁！

从上面已经看到了：读锁和写锁是互斥的，读写操作是串行。

• 如果某个进程想要获取读锁，同时另外一个进程想要获取写锁。在 mysql 中，写锁是优先于读锁的！

• 写锁和读锁优先级的问题是可以通过参数调节的：max_write_lock_count和low-priority-updates

MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后， 只有持有锁的线程可以对表进行更新操作。 其他线程的读、 写操作都会等待，直到锁被释放为止。

默认情况下，写锁比读锁具有更高的优先级：当一个锁释放时，这个锁会优先给写锁队列中等候的获取锁请求，然后再给读锁队列中等候的获取锁请求。

这也正是 MyISAM 表不太适合于有大量更新操作和查询操作应用的原因，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。同时，一些需要长时间运行的查询操作，也会使写线程“饿死” ，应用中应尽量避免出现长时间运行的查询操作（在可能的情况下可以通过使用中间表等措施对 SQL 语句做一定的“分解” ，使每一步查询都能在较短时间完成，从而减少锁冲突。如果复杂查询不可避免，应尽量安排在数据库空闲时段执行，比如一些定期统计可以安排在夜间执行）。

注意：

MyISAM 支持查询与插入操作的并发进行，也可以通过系统变量concurrent_insert指定哪种模式。在 MyISAM 中默认：如果 MyISAM 表的中间没有被删除的行的话，那 MyISAM 是允许在一个进程读表的同时，另一个进程从表尾做插入记录的。但是 INNODB 是不支持的。

乐观锁和悲观锁

无论是 Read committed 还是 Repeatable read 隔离级别，都是为了解决读写冲突的问题，现在考虑一个问题：有一张数据库表 USER，只有 id、name 字段，现在有 2 个请求同时操作表 A，过程如下：（模拟更新丢失，虽然不是很恰当）

1. 操作 1 查询出 name="zhangsan"
2. 操作 2 也查询出 name="zhangsan"
3. 操作 1 把 name 字段数据修改成 lisi 并提交
4. 操作 2 把 name 字段数据修改为 wangwu 并提交

那么操作 1 的更新丢失啦，即一个事务的更新覆盖了其它事务的更新结果，解决上述更新丢失的方式有如下 3 种：

• 使用 Serializable 隔离级别，事务是串行执行的！
• 乐观锁
• 悲观锁

悲观锁

一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。

我们使用悲观锁的话其实很简单(手动加行锁就行了)：select * from xxxx for update，在 select 语句后边加了for update相当于加了排它锁(写锁)，加了写锁以后，其他事务就不能对它修改了！需要等待当前事务修改完之后才可以修改。也就是说，如果操作 1 使用select ... for update，操作 2 就无法对该条记录修改了，即可避免更新丢失。

乐观锁

乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。

乐观锁不是数据库层面上的锁，需要用户手动去加的锁。一般我们在数据库表中添加一个版本字段version来实现，例如操作 1 和操作 2 在更新 User 表的时，执行语句如下：

update A set Name=lisi,version=version+1 where ID=#{id} and version\=#{version}

此时即可避免更新丢失。

什么是乐观锁，什么是悲观锁 - 简书 (opens new window)

MyISAM 加表锁方法

MyISAM 在执行查询语句（SELECT）前，会自动给涉及的表加读锁，在执行更新操作 （UPDATE、DELETE、INSERT 等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用 LOCK TABLE 命令给 MyISAM 表显式加锁。

在自动加锁的情况下，MyISAM 总是一次获得 SQL 语句所需要的全部锁，这也正是 MyISAM 表不会出现死锁（Deadlock Free）的原因。

MyISAM 存储引擎支持并发插入，以减少给定表的读和写操作之间的争用：

如果 MyISAM 表在数据文件中间没有空闲块，则行始终插入数据文件的末尾。 在这种情况下，你可以自由混合并发使用 MyISAM 表的 INSERT 和 SELECT 语句而不需要加锁——你可以在其他线程进行读操作的时候，同时将行插入到 MyISAM 表中。 文件中间的空闲块可能是从表格中间删除或更新的行而产生的。 如果文件中间有空闲快，则并发插入会被禁用，但是当所有空闲块都填充有新数据时，它又会自动重新启用。 要控制此行为，可以使用 MySQL 的 concurrent_insert 系统变量。

如果你使用 LOCK TABLES 显式获取表锁，则可以请求 READ LOCAL 锁而不是 READ 锁，以便在锁定表时，其他会话可以使用并发插入。

• 当 concurrent_insert 设置为 0 时，不允许并发插入。
• 当 concurrent_insert 设置为 1 时，如果 MyISAM 表中没有空洞（即表的中间没有被删除的行），MyISAM 允许在一个线程读表的同时，另一个线程从表尾插入记录。这也是 MySQL 的默认设置。
• 当 concurrent_insert 设置为 2 时，无论 MyISAM 表中有没有空洞，都允许在表尾并发插入记录。

行锁

InnoDB 和 MyISAM 有两个本质的区别：InnoDB 支持行锁、InnoDB 支持事务。

InnoDB 实现了以下两种类型的行锁：

• 共享锁（S 锁、读锁）： 允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。即多个客户可以同时读取同一个资源，但不允许其他客户修改。

• 排他锁（X 锁、写锁)： 允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的读锁和写锁。写锁是排他的，写锁会阻塞其他的写锁和读锁。

另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁：

• 意向共享锁（IS）： 事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的 IS 锁。

• 意向排他锁（IX）： 事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的 IX 锁。

• 意向锁也是数据库隐式帮我们做了，不需要程序员关心！

InnoDB 加锁方法

• 意向锁是 InnoDB 自动加的， 不需用户干预。

• 对于 UPDATE、 DELETE 和 INSERT 语句， InnoDB 会自动给涉及数据集加排他锁（X)；

• 对于普通 SELECT 语句，InnoDB 不会加任何锁；

• 事务可以通过以下语句显式给记录集加共享锁或排他锁：

  共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 其他 session 仍然可以查询记录，并也可以对该记录加 share mode 的共享锁。但是如果当前事务需要对该记录进行更新操作，则很有可能造成死锁。 排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。其他 session 可以查询该记录，但是不能对该记录加共享锁或排他锁，而是等待获得锁

MVCC 行级锁

MVCC(Multi-Version ConcurrencyControl)多版本并发控制，可以简单地认为：MVCC 就是行级锁的一个变种(升级版)。

为什么需要 MVCC 呢？数据库通常使用锁来实现隔离性。最原生的锁，锁住一个资源后会禁止其他任何线程访问同一个资源。但是很多应用的一个特点都是读多写少的场景，很多数据的读取次数远大于修改的次数，而读取数据间互相排斥显得不是很必要。所以就使用了一种读写锁的方法，读锁和读锁之间不互斥，而写锁和写锁、读锁都互斥。这样就很大提升了系统的并发能力。之后人们发现并发读还是不够，又提出了能不能让读写之间也不冲突的方法，就是读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务 session 会看到自己特定版本的数据。当然快照是一种概念模型，不同的数据库可能用不同的方式来实现这种功能。

在表锁中我们读写是阻塞的，基于提升并发性能的考虑，MVCC 一般读写是不阻塞的(很多情况下避免了加锁的操作)。

可以简单的理解为：对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，使得读取时可以完全不加锁。

MVCC 只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和 MVCC 不兼容, 因为 READ UNCOMMITTED 总是读取最新的数据行, 而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

Redo log, bin log, Undo log

undo log 用于多版本控制撤回和事务回滚，bin log 用于主从复制，redo log 用于数据写入磁盘之前的缓存，当数据库重启时，可以从该文件中进行恢复。

InnoDB 中通过 undo log 实现了数据的多版本，而并发控制通过锁来实现。

undo log 用于当进行数据修改时事务的回滚，用于数据的撤回操作，它记录了修改的反向操作，比如，插入对应删除，修改对应修改为原来的数据，通过 undo log 可以实现事务回滚，并且可以根据 undo log 回溯到某个特定的版本的数据，实现 MVCC。MySQL Innodb 中存在多种日志，除了错误日志、查询日志外，还有很多和数据持久性、一致性有关的日志。

binlog，是 mysql 服务层产生的日志，常用来进行数据恢复、数据库复制，常见的 mysql 主从架构，就是采用 slave 同步 master 的 binlog 实现的, 另外通过解析 binlog 能够实现 mysql 到其他数据源（如 ElasticSearch)的数据复制。

redo log 记录了数据操作在物理层面的修改，mysql 中使用了大量缓存，缓存存在于内存中，修改操作时会直接修改内存，而不是立刻修改磁盘，当内存和磁盘的数据不一致时，称内存中的数据为脏页(dirty page)。为了保证数据的安全性，事务进行中时会不断的产生 redo log，在事务提交时进行一次 flush 操作，保存到磁盘中, redo log 是按照顺序写入的，磁盘的顺序读写的速度远大于随机读写。当数据库或主机失效重启时，会根据 redo log 进行数据的恢复，如果 redo log 中有事务提交，则进行事务提交修改数据。这样实现了事务的原子性、一致性和持久性。

一文理解 Mysql MVCC - 知乎 (opens new window)

事务的隔离级别

事务的隔离级别就是通过锁的机制来实现，锁的应用最终导致不同事务的隔离级别，只不过隐藏了加锁细节，事务的隔离级别有 4 种：

• Read uncommitted：会出现脏读，不可重复读，幻读

• Read committed：会出现不可重复读，幻读

• Repeatable read：会出现幻读(Mysql 默认的隔离级别，但是Repeatable read 配合 gap 锁（间隙锁）不会出现幻读！)

• Serializable：串行，避免以上的情况

Read uncommitted：出现的现象->脏读：一个事务读取到另外一个事务未提交的数据.

例子：A 向 B 转账，A 执行了转账语句，但 A 还没有提交事务，B 读取数据，发现自己账户钱变多了！B 跟 A 说，我已经收到钱了。A 回滚事务【rollback】，等 B 再查看账户的钱时，发现钱并没有多...

Read committed：出现的现象->不可重复读：一个事务读取到另外一个事务已经提交的数据，也就是说一个事务可以看到其他事务所做的修改.

例如：A 查询数据库得到数据，B 去修改数据库的数据，导致 A 多次查询数据库的结果都不一样【危害：A 每次查询的结果都是受 B 的影响的，那么 A 查询出来的信息就没有意思了】

Repeatable read：避免不可重复读是事务级别的快照！每次读取的都是当前事务的版本，即使被修改了，也只会读取当前事务版本的数据

虚读(幻读)：是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。和不可重复读类似，但虚读(幻读)会读到其他事务的插入的数据，导致前后读取不 一致，幻读的重点在于新增或者删除(数据条数变化)，不可重复读的重点是修改.

InnoDB 的间隙锁与 Next-Key 锁

当我们用范围条件检索数据而不是相等条件检索数据，并请求共享或排他锁时，InnoDB 会给符合范围条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”。

InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。

例子：假如 emp 表中只有 101 条记录，其 empid 的值分别是 1,2,...,100,101

Select * from emp where empid > 100 for update;

上面是一个范围查询，InnoDB 不仅会对符合条件的 empid 值为 101 的记录加锁，也会对 empid 大于 101（这些记录并不存在）的“间隙”加锁

InnoDB 使用间隙锁的目的有 2 个：

• 为了防止幻读(上面也说了，Repeatable read 隔离级别下再通过 GAP 锁即可避免了幻读)

• 满足恢复和复制的需要：MySQL 的恢复机制要求在一个事务未提交前，其他并发事务不能插入满足其锁定条件的任何记录，也就是不允许出现幻读

警告

• Next-Key Locks

A next-key lock is a combination of a record lock on the index record and a gap lock on the gap before the index record.

Next-Key Locks 是在存储引擎 innodb、事务级别在可重复读的情况下使用的数据库锁，官网上有介绍，Next-Key Lock 是记录上的索引的 Record Lock 和该索引到上一个索引之间的 Gap Lock 的组合。

innodb 默认的锁就是Next-Key locks。

• GAP 锁

gap 锁，又称为间隙锁。存在的主要目的就是为了防止在可重复读的事务级别下，出现幻读问题。

在可重复读的事务级别下面，普通的select读的是快照，不存在幻读情况，但是如果加上 for update 的话，读取是已提交事务数据，gap 锁保证 for update 情况下，不出现幻读。

gap 锁到底是如何加锁的呢

假如是 for update 级别操作，先看看几条总结的何时加锁的规则。

• 唯一索引

1. 精确等值检索，Next-Key Locks 就退化为记录锁，不会加 gap 锁
2. 范围检索，会锁住 where 条件中相应的范围，范围中的记录以及间隙，换言之就是加上记录锁和 gap 锁（至于区间是多大稍后讨论）。
3. 不走索引检索，全表间隙加 gap 锁、全表记录加记录锁

• 非唯一索引

1. 精确等值检索，Next-Key Locks 会对间隙加 gap 锁（至于区间是多大稍后讨论），以及对应检索到的记录加记录锁。
2. 范围检索，会锁住 where 条件中相应的范围，范围中的记录以及间隙，换言之就是加上记录锁和 gap 锁（至于区间是多大稍后讨论）。
3. 非索引检索，全表间隙 gap lock，全表记录 record lock

ref: 深入了解 mysql--gap locks,Next-Key Locks - aizhen - 博客园 (opens new window)

死锁

产生原因

所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的 InnoDB。

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

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

2、产生示例

案例

需求：将投资的钱拆成几份随机分配给借款人。

起初业务程序思路是这样的：

投资人投资后，将金额随机分为几份，然后随机从借款人表里面选几个，然后通过一条条select for update 去更新借款人表里面的余额等。

例如：两个用户同时投资，A 用户金额随机分为 2 份，分给借款人 1，2

B 用户金额随机分为 2 份，分给借款人 2，1，由于加锁的顺序不一样，死锁当然很快就出现了。

对于这个问题的改进很简单，直接把所有分配到的借款人直接一次锁住就行了。

Select * from xxx where id in (xx,xx,xx) for update

在 in 里面的列表值 mysql 是会自动从小到大排序，加锁也是一条条从小到大加的锁

锁总结

表锁其实我们程序员是很少关心它的：

• 在 MyISAM 存储引擎中，当执行 SQL 语句的时候是自动加的。

• 在 InnoDB 存储引擎中，如果没有使用索引，表锁也是自动加的。

现在我们大多数使用 MySQL 都是使用 InnoDB，InnoDB 支持行锁：

• 共享锁->读锁->S 锁

• 排它锁->写锁->X 锁

在默认的情况下，select 是不加任何行锁的，事务可以通过以下语句显式给记录集加共享锁或排他锁。

• 共享锁（S）：

• SELECT \* FROM table\_name WHERE ... LOCK IN SHARE MODE

• 排他锁（X)：

• SELECT \* FROM table\_name WHERE ... FOR UPDATE

排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。也就是其他事务不能使用“select ... in share mode”“select ... for update”“insert、update、delete”等，但是可以使用普通的 select，因为普通 select 不需要获得锁，也不会与共享锁或排它锁冲突。

InnoDB 基于行锁还实现了 MVCC 多版本并发控制，MVCC 在隔离级别下的 Read committed 和 Repeatable read 下工作。MVCC 实现了读写不阻塞。

一些优化锁性能的建议

1. 尽量使用较低的隔离级别；
2. 精心设计索引，并尽量使用索引访问数据，使加锁更精确，从而减少锁冲突的机会
3. 选择合理的事务大小，小事务发生锁冲突的几率也更小
4. 给记录集显示加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁
5. 不同的程序访问一组表时，应尽量约定以相同的顺序访问各表，对一个表而言，尽可能以固定的顺序存取表中的行。这样可以大大减少死锁的机会
6. 尽量用相等条件访问数据，这样可以避免间隙锁对并发插入的影响
7. 不要申请超过实际需要的锁级别
8. 除非必须，查询时不要显式加锁。 MySQL 的 MVCC 可以实现事务中的查询不用加锁，优化事务性能；MVCC 只在 COMMITTED READ（读提交）和 REPEATABLE READ（可重复读）两种隔离级别下工作
9. 对于一些特定的事务，可以使用表锁来提高处理速度或减少死锁的可能

参考资料

1. MySQL 的各种锁 - 姚春辉 - 博客园 (opens new window)
2. MySQL 锁总结 - 知乎 (opens new window)