MySQL的锁和事务隔离级别

如今的互联网，开发一个大型的多人 APP，你一定离不开数据库。而如何保证所有人能够高并发的进行读写一直是一个高难度的架构问题，先刨去高并发，保证一致性读写这个问题最常用的手段是事务，而实现一个事务的关键点在于锁机制。

今天我们就来介绍下 InnoDB 存储引擎如何在高并发下实现锁机制来满足一致性读写的原理和实现。

锁

数据库的锁机制是区别于文件系统的一个关键特性。用于管理对共享资源的并发访问。InnoDB 会在很多地方使用锁机制，比如操作缓冲池中的数据表、LRU 页列表、数据行，为了保证一致性和完整性，需要有锁的机制。

对于不同数据库，锁机制的设计和实现完全不同：

• MyISAM 引擎：表锁设计，并发读没有问题，并发写性能差。
• Microsoft SQL Server: 支持乐观并发和悲观并发，乐观并发下支持行级锁，维持锁的开销大，在行锁数量超过阈值后会升级为表锁。
• InnoDB 引擎: 支持行锁，提供一致性的非锁定读。行锁没有额外开销，性能不会下降。
• Oracle：和 InnoDB 引擎非常类似。

两类锁：lock 和 latch

数据库中 lock 和 latch 都可以称为锁，但是有很大的区别。

latch 一般称为闩锁，用于保证并发线程操作临界资源的正确性，作用对象是内存数据结构，要求锁定时间非常短，不会检测死锁。在 InnoDB 引擎中又分为 mutex（互斥量）和 rwlock（读写锁）。

lock 是用来锁定数据库中的对象，如表、页、行，作用对象是事务，在 commit/rollback 后释放，会检测死锁。分为行锁、表锁、意向锁。

我们下面的锁指的都是 lock 类锁。

四种锁类型

InnoDB 支持四种锁：

• 共享锁（S Lock）：允许事务读一行数据
• 排他锁（X Lock）：允许事务删除或更新一行数据
• 意向共享锁（Intention S Lock）：事务想要获得一张表中某几行的共享锁
• 意向排他锁（Intention X Lock）：事务想要获得一张表中某几行的排他锁

当事务 T1 获取了行 r 的共享锁，由于读取不会改变行数据，因此事务 T2 也可以直接获得行 r 的共享锁，此时称为锁兼容（Lock Compatible）。

而当事务 T3 想要获取行 r 的排他锁进行修改数据时，就需要等待 T1/T2 释放行共享锁，此时称为锁不兼容。

S 锁和 X 锁都是行锁，而 IS 锁和 IX 锁都为意向锁，属于表锁。意向锁的设计是为了在一个事务中揭示下一行将被请求的锁类型，即在表锁的更细粒度进行锁定。由于 InnoDB 支持表锁，因此意向锁不会阻塞除全表扫描外的任何请求。

锁的兼容性：

	IS	IX	S	X
IS	兼容	兼容	兼容	不兼容
IX	兼容	兼容	不兼容	不兼容
S	兼容	不兼容	兼容	不兼容
X	不兼容	不兼容	不兼容	不兼容

存储事务和锁信息的三张表

我们可以通过 show engine innodb status 命令在事务部分查看当前锁请求的信息。

从 InnoDB1.0 开始，在 INFORMATION_SCHEMA 架构下添加了 INNODB_TRX（transaction 事务表）、INNODB_LOCKS（锁表）、INNODB_LOCK_WAITS（锁等待表），通过这三张表，可以让我们实时监控当前事务并分析可能存在的表问题。

三个表的定义分别为：

INNODB_TRX
trx_id	InnoDB 存储引擎内部唯一的事务 ID
trx_state	当前事务的状态
trx_started	事务的开始时间
trx_requested_lock_id	等待事务的锁 IDC，当状态不为 LOCK WAIT 时为 NULL
trx_wait_started	事务等待开始的时间
trx_weight	事务的权重，反映一个事务修改和锁定的行数。当需要回滚时，选择该值最小的事务进行回滚
trx_mysql_thread_id	MySQL 的线程 ID，show processlist 显示的结果
trx_query	事务运行的 SQL 语句

INNODB_LOCKS
lock_id	锁 ID
lock_trx_id	事务 ID
lock_mode	锁的模式
lock_type	锁的类型，表锁或行锁
lock_table	要加锁的表
lock_index	锁住的索引
lock_space	锁对象的 space id
lock_page	事务锁定页的数量，表锁时为 NULL
lock_rec	事务锁定行的数量，表锁时为 NULL
lock_data	事务锁定记录的主键值，表锁时为 NULL

INNODB_LOCK_WAITS
requesting_trx_id	申请锁资源的事务 ID
requesting_lock_id	申请的锁的 ID
blocking_trx_id	阻塞的事务 ID
blocking_lock_id	阻塞的锁的 ID

通过 INNODB_TRX 我们可以看到所有的事务，以及事务是否被阻塞，阻塞的锁 ID 是什么。
之后，通过 INNODB_LOCKS 查看所有的锁信息。
之后，通过 INNODB_LOCK_WAITS 可以查看到锁的等待信息以及阻塞关系。

通过这三种表能够较为清晰的查看事务和锁的情况，也可以联合查询，在下面的一些场景下我们会来展示这三个表的内容。

隔离级别

首先我们来说下数据库的四种事务隔离级别：

• READ UNCOMMITTED（0）: 浏览访问级别，存在脏读、不可重复读、幻读
• READ COMMITTED（1）: 游标稳定级别，存在不可重复度、幻读
• REPEATABLE READ（2）: 存在幻读
• SERIALIZABLE（3）: 隔离级别，保证事务安全，但完全串行，性能低

这四种事务隔离级别是指定的 SQL 标准，InnoDB 默认的隔离级别是 REAPEATABLE READ，但与其他数据库不同的时，它同时使用了 Next-Key-Lock 锁的算法，能够避免幻读的产生，因此能够完全满足事务的隔离性要求，即达到 SERIALIZABLE 隔离级别。

隔离级别越低，事务请求的锁越少或持锁时间越短，因此大部分数据库的默认隔离级别为 READ COMMITED。但是有相关的分析也指出，隔离级别的性能开销几乎一样，因此用户无须通过调整隔离级别来提高性能。

查看和修改事务隔离级别的命令:

mysql> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+
1 row in set (0.00 sec)

mysql> set session transaction isolation level SERIALIZABLE;
Query OK, 0 rows affected (0.00 sec)

示例中修改了本次会话的事务隔离级别，如果需要修改全局参数，可以替换 session 为 global。如果想要永久修改，需要修改配置文件：

[mysqld]
transaction-isolation = READ-COMMITED

在 SERIALIZABLE 的事务隔离级别，InnoDB 会对每个 SELECT 语句后自动加上 LOCK IN SHARE MODE，来对读操作加上一个共享锁，因此不再支持一致性的非锁定读。

由于 InnoDB 在 REPEATABLE READ 隔离级别就可以达到 SERIALIZABLE，因此一般不用使用最高隔离级别。

一致性非锁定读和多版本并发控制

一致性非锁定读（consistent nonlocking read）是指 InnoDB 通过行多版本控制（Multi Version Concurrency Control, MVCC）的方法来读取当前执行时间数据库中行的数据。

即如果读取的行正在执行变更操作，这时读取不会等待行锁的释放，而是会读取行的一个快照数据。快照是指该行的一个历史数据，通过 undo 操作来完成。这种方式极大提高了数据库的并发性，这也是 InnoDB 的默认设置。

快照是当前行的一个历史版本，但可能存在多个版本，行数据存在多个快照数据，这种技术成为行多版本技术，由此带来的并发控制，称为多版本并发控制（MVCC）。InnoDB 在 READ COMMITED 和 REPEATABLE READ 隔离级别时，会使用非锁定的一致性读，但是在这两种隔离级别使用的快找数据定义却不同：

• READ COMMITED: 总是读取最新一份快照
• REPEATABLE READ: 总是读取事务开始时的行数据版本

我们执行一个示例：

一致性非锁定读
时间	会话 A	会话 B
1	BEGIN
2	select * from z where a = 3;
3		BEGIN
4		update z set b=2 where a=3;
5	select * from z where a = 3;
6		COMMIT;
7	select * from z where a = 3;
8	COMMIT;

在这个例子中我们可以清晰的看到 0、1、2 三种隔离级别的区别：

# 在事务开始前我们可以分别调整为 0、1、2 三种隔离级别，来查看不同的输出
mysql> set session transaction isolation level READ UNCOMMITTED;
Query OK, 0 rows affected (0.00 sec)

mysql> select @@tx_isolation;
+------------------+
| @@tx_isolation   |
+------------------+
| READ-UNCOMMITTED |
+------------------+
1 row in set (0.00 sec)

# A 会话：T1 事务
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from z where a = 3;
+---+------+
| a | b    |
+---+------+
| 3 |    1 |
+---+------+
1 row in set (0.00 sec)

# B 会话：T2 事务
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update z set b=2 where a=3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# A 会话：T1 事务，如果此时隔离级别是 READ-UNCOMMITTED，因为此刻事务 2 可能会回滚，所以出现了脏读
mysql> select * from z where a=3;
+---+------+
| a | b    |
+---+------+
| 3 |    2 |
+---+------+
1 row in set (0.00 sec)

# A 会话：T1 事务，如果此时隔离级别是大于 READ-UNCOMMITTED 的更高级别
mysql> select * from z where a=3;
+---+------+
| a | b    |
+---+------+
| 3 |    1 |
+---+------+
1 row in set (0.00 sec)

# B 会话：T2 事务
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

# A 会话：T1 事务，如果此时隔离级别是 READ-COMMITTED，因为数据和事务开始时读取的出现了不一致，因此称为不可重复读，能够读到其他事务的结果，违反了事务的隔离性
mysql> select * from z where a=3;
+---+------+
| a | b    |
+---+------+
| 3 |    2 |
+---+------+
1 row in set (0.00 sec)

# A 会话：T1 事务，如果此时隔离级别是大于 READ-COMMITTED 的更高级别
mysql> select * from z where a=3;
+---+------+
| a | b    |
+---+------+
| 3 |    1 |
+---+------+
1 row in set (0.00 sec)

# A 会话：T1 事务
mysql> commit;
Query OK, 0 rows affected (0.00 sec)

一致性锁定读和 SERIALIZABLE 隔离

在默认的 REPEATABLE READ 隔离级别时，InnoDB 使用的是一致性非锁定读。但有时我们也需要显示的指定使用一致性锁定读来保证读取操作时对数据进行加锁达到一致性。这要求数据库支持锁定读加锁语句：

• select … for update: 读取时对行记录加 X 锁
• select … lock in share mode：读取时对行记录加一个 S 锁

这两种锁必须在一个事务中，当事务提交后锁也就释放了，因此务必加上 BEGIN, START TRANSACTION 或者 SET AUTOCOMMIT=0。

我们在前面隔离级别时也说过 SERIALIZABLE 隔离级别会对读操作自动加上 LOCK IN SHARE MODE 指令来加上一个共享锁，因此不再支持一致性的非锁定读。这也是隔离级别 3 的一大特性。

总结

由于锁的概念非常重要，这里先讲了锁的概念、锁的类型、锁的信息查看、事务的隔离级别和区别，后面我们会继续说锁的算法、锁的三种问题和幻读、死锁和锁升级。

喜欢的可以先点赞，我会继续第二篇。

参考资料

1. 《MySQL 技术内幕 InnoDB 存储引擎》P6 锁