共计 2960 个字符,预计需要花费 8 分钟才能阅读完成。
Mysql 锁机制简介
一、锁分类(按照锁的粒度分类)
Mysql 为了解决并发、数据安全的问题,使用了锁机制。
可以按照锁的粒度把数据库锁分为表级锁和行级锁。
- 表级锁
Mysql 中锁定 粒度最大 的一种锁,对当前操作的整张表加锁,实现简单, 资源消耗也比较少,加锁快,不会出现死锁。其锁定粒度最大,触发锁冲突的概率最高,并发度最低,MyISAM 和 InnoDB 引擎都支持表级锁。
-
行级锁
Mysql 中锁定 粒度最小 的一种锁,只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小,并发度高,但加锁的开销也最大,加锁慢,会出现死锁。
InnoDB 支持的行级锁,包括如下几种。
-
Record Lock
:对索引项加锁,锁定符合条件的行。其他事务不能修改和删除加锁项; -
Gap Lock
:对索引项之间的“间隙”加锁,锁定记录的范围(对第一条记录前的间隙或最后一条将记录后的间隙加锁),不包含索引项本身。其他事务不能在锁范围内插入数据,这样就防止了别的事务新增幻影行。 -
Next-key Lock
:锁定索引项本身和索引范围。即 Record Lock 和 Gap Lock 的结合。可解决幻读问题。
-
虽然使用行级索具有粒度小、并发度高等特点,但是表级锁有时候也是非常必要的:
- 事务更新大表中的大部分数据直接使用表级锁效率更高;
- 事务比较复杂,使用行级索很可能引起死锁导致回滚。
二、锁分类(按照是否可写分类)
表级锁和行级锁可以进一步划分为 共享锁(s)
和 排他锁(X)
。
-
共享锁(s):
共享锁(Share Locks,简记为 S)又被称为读锁,其他用户可以并发读取数据,但任何事务都不能获取数据上的排他锁,直到已释放所有共享锁。
共享锁 (S 锁) 又称为读锁,若事务 T 对数据对象 A 加上 S 锁,则事务 T 只能读 A;其他事务只能再对 A 加 S 锁,而不能加 X 锁,直到 T 释放 A 上的 S 锁。这就保证了其他事务可以读 A,但在 T 释放 A 上的 S 锁之前不能对 A 做任何修改。
-
排他锁(X):
排它锁((Exclusive lock, 简记为 X 锁))又称为写锁 ,若事务 T 对数据对象 A 加上 X 锁,则只允许 T 读取和修改 A,其它任何事务都不能再对 A 加任何类型的锁,直到 T 释放 A 上的锁。它防止任何其它事务获取资源上的锁,直到在事务的末尾将资源上的原始锁释放为止。在更新操作(INSERT、UPDATE 或 DELETE) 过程中始终应用排它锁。
两者之间的区别:
- 共享锁(S 锁):如果事务 T 对数据 A 加上共享锁后,则其他事务只能对 A 再加共享锁,不 能加排他锁。获取共享锁的事务只能读数据,不能修改数据。
- 排他锁(X 锁):如果事务 T 对数据 A 加上排他锁后,则其他事务不能再对 A 加任任何类型的封锁。获取排他锁的事务既能读数据,又能修改数据。
三、另外两个表级锁:IS 和 IX
当一个事务需要给自己需要的某个资源加锁的时候,如果遇到一个共享锁正锁定着自己需要的资源的时候,自己可以再加一个共享锁,不过不能加排他锁。
但是,如果遇到自己需要锁定的资源已经被一个排他锁占有之后,则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。
而意向锁的作用就是当一个事务在需要获取资源锁定的时候,如果遇到自己需要的资源已经被排他锁占用的时候,该事务可以需要锁定行的表上面添加一个合适的意向锁。
如果自己需要一个共享锁,那么就在表上面添加一个意向共享锁。而如果自己需要的是某行(或者某些行)上面添加一个排他锁的话,则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个,但是意向排他锁同时只能有一个存在。
InnoDB 另外的两个表级锁:
- 意向共享锁(IS):表示事务准备给数据行记入共享锁,事务在一个数据行加共享锁前必须先取得该表的 IS 锁。
- 意向排他锁(IX):表示事务准备给数据行加入排他锁,事务在一个数据行加排他锁前必须先取得该表的 IX 锁。
注意:
- 这里的意向锁是表级锁,表示的是一种意向,仅仅表示事务正在读或写某一行记录,在真正加行锁时才会判断是否冲突。意向锁是 InnoDB 自动加的,不需要用户干预。
- IX,IS 是表级锁,不会和行级的 X,S 锁发生冲突,只会和表级的 X,S 发生冲突。
InnoDB 的锁机制兼容情况如下:
首先把四个名字的含义理解了:
- X 理解为独占一个表(exclusive)
- S 理解为共享一个表(整个表共享读)
- IX 理解为有意向写这张表的某一行(有意向独占某一行、先占一个坑)
- IS 理解为有意向读这张表的某一行
所以锁机制兼容情况可以表达为:
- X 是独占整个表,当表中已经存在了 X、S、IX、IS 任意一种锁,X 锁一定加不上了,因为无法满足独占。同理,表中已经存在 X,其他锁都加不上了(必须独占)
- IX 和 S 锁不兼容,IX 是独占某一行,既然 IX 占领了某一行,那么就不能 S 整个表共享读了
- IX 和 IS 兼容,某一行有意向独占和另一行有意向共享读是可以成立的
- IX 和 IX 之间兼容,可以存在 IX 想要独占 row_a,另一个 IX 想要独占 row_b,只要 a≠b 即可成立
- 整个兼容表其实是对称的 (行列顺序都按照 X、S、IX、IS)
四、死锁和避免死锁
InnoDB 的行级锁是基于索引实现的,如果查询语句为命中任何索引,那么 InnoDB 会使用表级锁。
此外,InnoDB 的行级锁是针对索引加的锁,不针对数据记录,因此即使访问不同行的记录,如果使用了相同的索引键仍然会出现锁冲突,还需要注意的是,在通过
SELECT ...LOCK IN SHARE MODE;
或
SELECT ...FOR UPDATE;
使用锁的时候,如果表没有定义任何索引,那么 InnoDB 会创建一个隐藏的聚簇索引并使用这个索引来加记录锁。
此外,不同于 MyISAM 总是一次性获得所需的全部锁,InnoDB 的锁是逐步获得的,当两个事务都需要获得对方持有的锁,导致双方都在等待,这就产生了死锁。
发生死锁后,InnoDB 一般都可以检测到,并使一个事务释放锁回退,另一个则可以获取锁完成事务,我们可以采取以上方式避免死锁:
- 通过表级锁来减少死锁产生的概率;
- 多个程序尽量约定以相同的顺序访问表(这也是解决并发理论中哲学家就餐问题的一种思路);
- 同一个事务尽可能做到一次锁定所需要的所有资源。
五、总结与补充
MyISAM 和 InnoDB 存储引擎使用的锁:
- MyISAM 采用表级锁(table-level locking)。
- InnoDB 支持行级锁 (row-level locking) 和表级锁, 默认为行级锁。
表级锁和行级锁对比:
- 表级锁:Mysql 中锁定 粒度最大 的一种锁,对当前操作的整张表加锁,实现简单,资源消耗也比较少,加锁快,不会出现死锁。其锁定粒度最大,触发锁冲突的概率最高,并发度最低,MyISAM 和 InnoDB 引擎都支持表级锁。
- 行级锁:Mysql 中锁定 粒度最小 的一种锁,只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小,并发度高,但加锁的开销也最大,加锁慢,会出现死锁。
补充:
页级锁: MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快,但冲突多,行级冲突少,但速度慢。页级进行了折衷,一次锁定相邻的一组记录。BDB 支持页级锁。开销和加锁时间界于表锁和行锁之间,会出现死锁。锁定粒度界于表锁和行锁之间,并发度一般。
参考:
《深入浅出 MySQL》
《Java 工程师修炼之道》
原文链接:https://blog.csdn.net/qq_3433…