MySQL 的锁机制

发表于 标签

在计算机科学中，锁是在执行多线程时用于强行限制资源访问的同步机制，即用于在并发控制中保证对互斥要求的满足。

本文主要以 MySQL 为例，讲述几个锁的概念 (行级锁、页级锁、表级锁、共享锁、排它锁等)，这些概念的范畴不限于 MySQL，在并发系统上均有应用。

行级锁，页级锁，表级锁

在 DBMS 中，可以按照锁的粒度把数据库锁分为行级锁 (INNODB 引擎)、表级锁 (MYISAM 引擎) 和页级锁 (BDB 引擎 )。

行级锁

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

特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

表级锁

表级锁是 MySQL 中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分 MySQL 引擎支持。最常使用的 MYISAM 与 INNODB 都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。

特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。

页级锁

页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。BDB 支持页级锁

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

常用存储引擎及其锁机制

  1. MyISAM 和 MEMORY 采用表级锁 (table-level locking)

  2. BDB 采用页面锁 (page-level locking) 或表级锁，默认为页面锁

  3. InnoDB 支持行级锁 (row-level locking) 和表级锁，默认为行级锁

Innodb 中的行锁与表锁

前面提到过，在 Innodb 引擎中既支持行锁也支持表锁，那么什么时候会锁住整张表，什么时候或只锁住一行呢？

InnoDB 行锁是通过给索引上的索引项加锁来实现的，这一点 MySQL 与 Oracle 不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB 这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB 才使用行级锁，否则，InnoDB 将使用表锁！

值得注意的是，DBMS 对于主键会自动生成唯一索引，所以主键也是一个特殊的索引。即通过主键进行查询也能实现行级锁。

在实际应用中，要特别注意 InnoDB 行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。

行级锁都是基于索引的，如果一条 SQL 语句用不到索引是不会使用行级锁的，会使用表级锁。行级锁的缺点是：由于需要请求大量的锁资源，所以速度慢，内存消耗大。

行级锁与死锁

MyISAM 中是不会产生死锁的，因为 MyISAM 总是一次性获得所需的全部锁，要么全部满足，要么全部等待。而在 InnoDB 中，锁是逐步获得的，就造成了死锁的可能。

在 MySQL 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条 sql 语句操作了主键索引，MySQL 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL 会先锁定该非主键索引，再锁定相关的主键索引。

在 UPDATE、DELETE 操作时，MySQL 不仅锁定 WHERE 条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的 next-key locking。

当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。

发生死锁后，InnoDB 一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。

避免死锁

如何避免死锁，这里只介绍常见的三种

1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。

2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；

3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率

共享锁，排它锁，意向锁

行级锁分为共享锁和排他锁两种，下面将详细介绍共享锁及排他锁的概念、使用方式及注意事项等。

共享锁 (Share Lock，SLock)

共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。

如果事务 T 对数据 A 加上共享锁后，则其他事务只能对 A 再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。

语法：SELECT ... LOCK IN SHARE MODE;

在查询语句后面增加 LOCK IN SHARE MODE，Mysql 会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。其他线程也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。

排他锁（eXclusive Lock，XLock）

排他锁又称写锁，如果事务 T 对数据 A 加上排他锁后，则其他事务不能再对 A 加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。

语法：SELECT ... FOR UPDATE;

在查询语句后面增加 FOR UPDATE，Mysql 会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

意向锁（Intent Lock）

InnoDB 还有两个表锁：

意向共享锁（IS）：表示事务准备给数据行加入共享锁，也就是说给一个数据行加共享锁前必须先取得该表的 IS 锁

意向排他锁（IX）：类似上面，表示事务准备给数据行加入排他锁，说明事务在一个数据行加排他锁前必须先取得该表的 IX 锁

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

对于 insert、update、delete，InnoDB 会自动给涉及的数据加排他锁（X）；对于一般的 Select 语句，InnoDB 不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。

共享锁：SELECT ... LOCK IN SHARE MODE;

排他锁：SELECT ... FOR UPDATE;

乐观锁，悲观锁

数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。

乐观并发控制 (乐观锁) 和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。

无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像 memcache、hibernate、tair 等都有类似的概念。

针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为 DBMS 中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在 DBMS 中，悲观锁正是利用数据库本身提供的锁机制来实现的。

悲观锁

悲观并发控制（又名 “悲观锁”，Pessimistic Concurrency Control，缩写 “PCC”）是一种并发控制的方法。

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度 (悲观) ，因此，在整个数据处理过程中，将数据处于锁定状态。

悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

在数据库中，悲观锁的流程如下： （1）在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。 （2）如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。 （3）如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

下面讲述在 MySQL InnoDB 中使用悲观锁，要使用悲观锁，我们必须关闭 MySQL 数据库的自动提交属性，因为 MySQL 默认使用 autocommit 模式，也就是说，当你执行一个更新操作后，MySQL 会立刻将结果进行提交。

1
2
3
4
5
6
7
8
9
10
11
12
//0.关闭自动提交属性
set autocommit=0;
//1.开始事务
begin;/begin work;/start transaction; 
//2.查询出商品信息
select status from t_goods where id=1 for update;
//3.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//4.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

上面的查询语句中，我们使用了 select…for update 的方式，这样就通过排他锁的实现了悲观锁。此时在 t_goods 表中，id 为 1 的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

优点与不足：悲观并发控制实际上是 “先取锁再访问” 的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数

乐观锁

乐观并发控制（又名 “乐观锁”，Optimistic Concurrency Control，缩写 “OCC”）是一种并发控制的方法。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。实现数据版本可以通过使用版本号或使用时间戳。实现流程如下：

（1）为数据表增加一个表示版本标识的字段，用于存储版本号或时间戳 （2）当读取数据时，将版本标识的值一同读出 （3）当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本标识与第一次取出来的版本标识值相等，则同时更新数据和版本号，否则认为是过期数据，返回错误给用户处理

下图为该流程的示意过程：

参考: MySQL 中的行级锁，表级锁，页级锁 MySQL 中的共享锁与排他锁 深入理解乐观锁与悲观锁 mysql 悲观锁总结和实践 mysql 乐观锁总结和实践