likes
comments
collection
share

再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

作者站长头像
站长
· 阅读数 16

一、ACID的概念(原子性、一致性、隔离性、持久性)

事务性数据库实现的是

  • 原子性: 支持未完成的数据修改回滚的机制
  • 一致性:力所能及的数据合法性检查
  • 隔离性: 保证数据并发的修改的规则
  • 持久性:使用基于持久化存储(磁盘、SSD)的方式对数据进行存储

1. Atomicity 原子性

在ACID语境下,原子性是指一组对数据库的改变,要么最终成功执行完成,要不就全部回滚。

这就要求数据库系统要实现某种回滚的机制,比如redo/undo log。所以,也许这里用术语”revertability“可能更适合。与事务性数据库相比,一些NoSQL的数据库也声称支持原子性,但是意义不同。比如Redis事务的原子性的意思可能更接近于“一组指令被执行时,不受其他指令的干扰”,而不是“可以回滚”。

2. Consistency 一致性

在ACID语境下,一致性指的是,在事务完成前后,数据都是要在业务意义上是”正确的“

所以也许术语”correctness“更适合这里的意思。但如果这样定义的话,数据库的位置就很尴尬了,因为保证业务是否正确是要业务代码来最终保证的,数据库能做的非常有限。目前数据库里实现的约束检查,比如唯一约束、外键约束、一些enum测检查、一些数据类型/长度/有效数字的检查等等,对于简单的场景还可以使用。对于复杂的业务约束检查,很难或者不可能实现。有一类数据正确性问题正是由于下面隔离性的使用不当而带来的。 真实复杂业务的数据正确性维护一般用正确的业务代码 + 合法性job来定时执行 + 数据库自身的简单合法性防护一起实现。

3. Isolation 隔离性

在ACID语境下,隔离性是指一组对数据库的并发修改互相不影响。

这个概念表面上看来并不是能说得通,因为如果并发修改的是互不相干的数据,那么自然隔离性可以得到满足;如果并发修改的是相关联的,或者就是同一份数据,就必然会相互影响。

那么,此时可以做的就是区分哪个修改优先级更加高,而高优先级的修改应该覆盖掉低优先级的修改。但是,现实往往更复杂,因为并发的修改并不一定能够讲明白先来后到的(要不怎么叫并发呢),此时谁应该生效无法很好的定义。另外一种情况是“先读取,再基于读取结果对数据进行修改”这样业务逻辑。比如,先找到可用的库存,有则扣减,没有则提示缺货;再比如先读取当前的计数值,再往上加1。这时保证隔离性的主要问题不在于隔离本身,而在于如果将读取作为对数据修改的前提条件,之后在对数据进行修改的一刹那,读取时的前提条件还是否满足。毕竟读取和写入是两个分开的指令,而在这两个指令中间可能夹杂其他事务对数据的修改。保持隔离性的一个简单做法是保证对关联数据的修改串行化,对应事务性数据库的“Serializable”隔离级别。保证串行化的一种方案是锁,通过锁定可以彻底避免竞争条件。但是大家都能明白加锁对数据库并发的性能负面影响很大,所以就衍生出了几种弱一些的隔离性保证——READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ。此外MVCC能够解决一部分锁带来的问题。这些内容在下文中会说明。

4. Duration 持久性

在ACID语境下,持久性是指对数据的修改,一旦完成,该结果就应当永远不丢失。

在现实当中,一般通过持久性存储设备(比如磁盘/SSD)写入并刷新来保证数据的持久性。如果觉得一个节点不靠谱,可以增加多个副本(replica)一起来保证持久;如果觉得这样还不够靠谱,可以在不同的地理位置的另一个数据中心做备份。实际上绝对的持久性是不存在的,因为整个存储层面有很多不确定因素,比如文件系统本身fsync指令实现有bug,磁盘的固件有bug,供电出现问题造成数据错乱,异步的数据复制没有生效等等。所以在现实当中的数据库,只能在当前成本和技术限制的约束下,尽量维持一定程度的持久性。

二、隔离级别概念

四种隔离级别

  • Read Uncommitted
  • Read Committed
  • Repeatable Read
  • Serializable

定义这4种隔离级别时,制定者主要围绕着基于锁的并发控制来说的。但是后来出现了MVCC,之后主流数据库都开始支持MVCC。有的数据库采用比较纯粹的MVCC实现,比如PostgreSQL;有的则是混杂的,比如MySQL InnoDB。这就会造成数据库的实现和标准的描述有很多出入。

1. Read Uncommitted 最不严格的隔离级别

Read Uncommitted允许脏读,但不允许脏写。

理论上,最不严格的隔离级别应该是不隔离。

不隔离很容易理解,不同的事务可以对同一数据并发的随便改:A事务改了一半的结果B能看到;B改了一半的结果A也能看到;如果A和B反复修改同一个数据,那么彼此的修改可以覆盖。数据系统在没有做隔离防护时,就一定会是这个样子。这样也就无所谓事务了。

这里数据访问冲突可以分为两种:

  1. Dirty Read,脏读。即一个事务的没提交之前的修改被另外一个事务可以看到。
  2. Dirty Write,脏写。即一个事务的没提交之前的修改可以被另外一个事务的修改覆盖掉。

其实脏读在某些场景下还是可以接受的,比如完全不需要“读取-计算-修改”逻辑的事务。这种事务完全不在意别的事物是怎么修改的,就是自己改自己的;要不就是业务上“就算是基于一个错误的前提进行了数据修改,结果也可以接受”的场景。

而脏写是无法被接受的,因为他会让事务原子性无法实现。试想以下A和B两个事务的行为(假设x的值一开始是0): 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦 事务B将事务A的修改覆盖了,将x改为2,然后回滚。但是事务A却commit了。此时x应该是多少呢?从事务A的角度可能应该是1,但是从事务B的角度应该是0。这种情况无论如何都不能自洽。因此,任何支持事务的数据库都有一个基本原则不论隔离级别是什么,脏写都是不允许的!! 如何避免脏写呢?答案很简单——使用锁。实际上,一般数据库都会使用排他锁来标记要修改的数据(update,delete,select … for update)。锁的存在可以保证——写要block写。这个规则永远生效。 在MySQL InnoDB中,这种锁被称为“X锁”。它的特性是,只要有一个事务获取了一条数据的X锁,其他事物如果也想获取这个锁,就必须等待,直到第一个事务提交/回滚后释放锁,或者等到超时自动回滚。例如上面的例子的第二行事务B尝试进行set x = 2就会被排他锁卡住。有很多教程会提示一些数据库的某些隔离级别是使用MVCC而不是锁的方案来实现的,说的好像用了MVCC就完全不需要锁。这是非常容易引起误解的。事务数据库对于写操作永远需要锁来避免脏写,即使是基于MVCC的数据库。所谓某个隔离级别使用MVCC不需要锁,仅仅是指在读取的时候是否需要锁。

所以,最不严格的隔离级别的隔离级别是允许脏读,但不允许脏写。这种隔离级别被称为Read Uncommitted。这种隔离级别一般不建议使用。事务应该是数据被修改的最小单位,而Read Uncommitted丧失了“事务”这个词本身存在的意义。虽然该隔离级别可以带来一些性能上的优势,但因为其容易造成数据由于并发操作带来的问题,所以应该用在不不太在意数据正确性的场景。但如果你的业务需要性能上的优势,就说明请求量很高,而请求量很高的业务一般很重要,不太可能不需要数据正确性。如果访问请求量不高,直接用默认的隔离级别(有的数据库是Read Committed,有的是Repeatable Read)就是了,没有必要去折腾数据库配置。 如果是高性能的简单数据操作(比如根据数据ID直接修改数据行),用Read Uncommitted是可行的。但既然这样,为什么不用一个正儿八经的NoSQL数据库(比如RocksDB),从而得到高的多写入性能?

Read Uncommitted在SQL92里被定义为最低级别的隔离。但在PostgreSQL中,Read Uncommitted压根就没有实现,设置Read Uncommitted等价于设置Read Committed。

简单来说,对于事务性数据库,Read Uncommitted是鸡肋一般的存在。

2. Read Committed和Repeatable Read

把这俩种隔离级别放一起说是因为它们的基本原则是一样的:读不block读和写,写不block读。只不过是发生了并行读写的隔离效果不太一样。此外,它们两个对OLTP业务代码的编写的影响差不多——它们都无法解决“写前提困境“。在深入讨论之前,这里先复述一遍这俩隔离级别的意思。

Read Committed是指一个事务能看到另外一个事务对一条数据记录已经提交的修改。

例如下面的操作序列(假设变量x的值一开始是0): 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦 这里可以看到事务A对x的两次读取,因为发生在事务B对x修改的前后,得到了不同的结果。事务A可以看到事务B已经提交的修改。

Repeatable Read是指一个事务一旦开始,反复读取一条数据记录,都会得到相同的结果。

或者说,假如有两个事务A和B,A在B之前开始,那么B对数据的修改对于事务A总是不可见的。例如下面的操作序列(假设变量x的值一开始是0): 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦 Repeatable Read的直观感觉仿佛是给事务做一个整个数据库做了一个快照,所以很多时候这种隔离级别又被称为Snapshot Isolation。"快照"的功能在一些场景下非常重要,如:

  1. 数据备份。例如数据库S从数据库M中复制数据,但是同时M数据库又被持续修改。S需要拿到一个M的数据快照,但是又不能真的把M给停了。
  2. 数据合法性检查。例如有两张数据表,一张记录了当时的交易总额,另外一张表记录了每个交易的金额。那么在读取数据时,如果没有快照的存在,交易金额的总和可能与当时的交易总额对不上,因为随着检查事务的进行,新的交易记录数据会被提交。这些新的提交会被检查事务看到。

在基于MVCC的数据库中,一般认为只实现了Read Committed和Repeatable Read两隔离级别。PostgreSQL在9.1以前,Serializable和Repeatable Read是一样的(PostgreSQL 9.1以后的Serializable增强了数据依赖性的检查)。

此外值得一提的是幻读的问题。在SQL92标准中提到了Repeatable Read中是可以出现幻读的——即一个事务尽管不能读取到后续其他事务对现有数据的修改,但是能够读取到插入的新数据。但是,基于MVCC的实现,Repeatable Read可以完全避免幻读(这岂不是更好)。无论MySQL还是PostgreSQL在Repeatable Read隔离级别都不会出现幻读。

三、锁的具体内容

锁看起来是很复杂的,因为有一大堆的东西和名词:排它锁,共享锁,表锁,页锁,间隙锁,意向排它锁,意向共享锁,行锁,读锁,写锁,乐观锁,悲观锁,死锁。

再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

1. 锁分类(按粒度)

相对于其他的数据库而言,MySQL的锁机制比较简单,最显著的特点就是不同的存储引擎支持不同的锁机制。根据不同的存储引擎,MySQL中锁的特性可以大致归纳如下: 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

1.1 表锁:

  1. 开销小,加锁快;
  2. 不会出现死锁;
  3. 锁定力度大,发生锁冲突概率高,并发度最低

1.2 行锁:

  1. 开销大,加锁慢;
  2. 会出现死锁;
  3. 锁定粒度小,发生锁冲突的概率低,并发度高

1.3 页锁:

  1. 开销和加锁速度介于表锁和行锁之间;
  2. 会出现死锁;
  3. 锁定粒度介于表锁和行锁之间,并发度一般

从上述的特点可见,很难笼统的说哪种锁最好,只能根据具体应用的特点来说哪种锁更加合适。仅仅从锁的角度来说的话:

  1. 表锁更适用于以查询为主,只有少量按索引条件更新数据的应用;
  2. 行锁更适用于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用。(PS:由于BDB已经被InnoDB所取代,我们只讨论MyISAM表锁和InnoDB行锁的问题)

不同的存储引擎支持的锁粒度是不一样的:

  1. InnoDB行锁和表锁都支持!
  2. MyISAM只支持表锁!
  3. InnoDB只有通过索引条件检索数据才使用行级锁,否则,InnoDB将使用表锁

也就是说,

  • InnoDB的行锁是基于索引的!
  • InnoDB的行锁是基于索引的!
  • InnoDB的行锁是基于索引的!

敲黑板划重点,重要的事情说三遍!!!

2. 表锁

表锁下分为两种模式:

  • 表读锁(Table Read Lock)
  • 表写锁(Table Write Lock)

从下图可以清晰看到,在表读锁和表写锁的环境下:

  1. 读读不阻塞:当前用户在读数据,其他的用户也在读数据,不会加锁
  2. 读写阻塞:当前用户在读数据,其他的用户不能修改当前用户读的数据,会加锁
  3. 写写阻塞:当前用户在修改数据,其他的用户不能修改当前用户正在修改的数据,会加锁

再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

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

如果某个进程想要获取读锁,同时另外一个进程想要获取写锁。在mysql里边,写锁是优先于读锁的!

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

值得注意的是:

MyISAM可以支持查询和插入操作的并发进行。 可以通过系统变量concurrent_insert来指定哪种模式,在MyISAM中它默认是:如果MyISAM表中没有空洞(即表的中间没有被删除的行),MyISAM允许在一个进程读表的同时,另一个进程从表尾插入记录。 但是InnoDB存储引擎是不支持的!

2.1 查询表级锁争用情况

可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺:

mysql> show status like 'table%';

Variable_nameValue
Table_locks_immediate2979
Table_locks_waited0

2 rows in set (0.00 sec))

如果Table_locks_waited的值比较高,则说明存在着较严重的表级锁争用情况。

  • 对MyISAM表的读操作,不会阻塞其他用户对同一表的读请求,但会阻塞对同一表的写请求;
  • 对MyISAM表的写操作,则会阻塞其他用户对同一表的读和写操作;
  • MyISAM表的读操作与写操作之间,以及写操作之间是串行的!
  • 当一个线程获得对一个表的写锁后,只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待,直到锁被释放为止。

2.2 如何加表锁

MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会自动给涉及的表加写锁,这个过程并不需要用户干预,因此,用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。显式加锁基本上都是为了方便而已,并非必须如此。

给MyISAM表显示加锁,一般是为了在一定程度模拟事务操作,实现对某一时间点多个表的一致性读取。例如,有一个订单表orders,其中记录有各订单的总金额total,同时还有一个订单明细表order_detail,其中记录有各订单每一产品的金额小计 subtotal,假设我们需要检查这两个表的金额合计是否相符,可能就需要执行如下两条SQL:

Select sum(total) from orders;
Select sum(subtotal) from order_detail;

这时,如果不先给两个表加锁,就可能产生错误的结果,因为第一条语句执行过程中,order_detail表可能已经发生了改变。因此,正确的方法应该是:

Lock tables orders read local, order_detail read local;
Select sum(total) from orders;
Select sum(subtotal) from order_detail;
Unlock tables;

要特别说明以下两点内容。

  • 上面的例子在LOCK TABLES时加了“local”选项,其作用就是在满足MyISAM表并发插入条件的情况下,允许其他用户在表尾并发插入记录,有关MyISAM表的并发插入问题,在后面的章节中还会进一步介绍。

  • 在用LOCK TABLES给表显式加表锁时,必须同时取得所有涉及到表的锁,并且MySQL不支持锁升级。也就是说,在执行LOCK TABLES后,只能访问显式加锁的这些表,不能访问未加锁的表;同时,如果加的是读锁,那么只能执行查询操作,而不能执行更新操作。其实,在自动加锁的情况下也基本如此,MyISAM总是一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁(Deadlock Free)的原因。

  • 注意,当使用LOCK TABLES时,不仅需要一次锁定用到的所有表,而且,同一个表在SQL语句中出现多少次,就要通过与SQL语句中相同的别名锁定多少次,否则也会出错!

    (1)对actor表获得读锁:

    mysql> lock table actor read;

    Query OK, 0 rows affected (0.00 sec)

    (2)但是通过别名访问会提示错误:

    mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = 'Lisa' and a.last_name = 'Tom' and a.last_name <> b.last_name;

    ERROR 1100 (HY000): Table 'a' was not locked with LOCK TABLES

    (3)需要对别名分别锁定:

    mysql> lock table actor as a read,actor as b read;

    Query OK, 0 rows affected (0.00 sec)

    (4)按照别名的查询可以正确执行:

    mysql> select a.first\_name,a.last\_name,b.first\_name,b.last\_name from actor a,actor b where a.first\_name = b.first\_name and a.first\_name = 'Lisa' and a.last\_name = 'Tom' and a.last\_name <> b.last\_name;

    first_namelast_namefirst_namelast_name
    LisaTomLISAMONROE

    1 row in set (0.00 sec)

3. 行锁

上边简单讲解了表锁的相关知识,我们使用Mysql一般是使用InnoDB存储引擎的。InnoDB和MyISAM有两个本质的区别:

  • InnoDB支持行锁
  • InnoDB支持事务

从上面也说了:我们是很少手动加表锁的。表锁对我们程序员来说几乎是透明的,即使InnoDB不走索引,加的表锁也是自动的!

我们应该更加关注行锁的内容,因为InnoDB一大特性就是支持行锁!

InnoDB实现了 读锁(共享锁、S锁)和 写锁(排他锁、X锁)两种类型的行锁。

X锁,S锁,读锁,写锁,共享锁,排它锁其实总共就两个锁,只不过它们有多个名字罢了~

3.1 读锁(共享锁、S锁)

允许一个事务去读一行,阻止其他事务获得相同数据集的写锁。

读锁是共享的,多个客户可以同时读取同一个资源,但不允许其他客户修改。

3.2 写锁(排他锁、X锁)

允许获得写锁的事务更新数据,阻止其他事务取得相同数据集的读锁和写锁。

写锁是排他的,写锁会阻塞其他的写锁和读锁。

4. 意向锁(Intention Locks)

为了允许行锁和表锁共存,实现多粒度锁机制,InnoDB还有两种内部使用的意向锁(Intention Locks),意向锁也是数据库隐式帮我们做了,不需要程序员操心!

这两种意向锁都是表锁:

4.1 意向读锁(意向共享锁、IS锁)

事务打算给数据行加行读锁,事务在给一个数据行加读锁前必须先取得该表的意向读锁。

4.2 意向写锁(意向排他锁、IX锁)

事务打算给数据行加行写锁,事务在给一个数据行加写锁前必须先取得该表的意向写锁。

5. MVCC和事务的隔离级别

数据库事务有不同的隔离级别,不同的隔离级别对锁的使用是不同的,锁的应用最终导致不同事务的隔离级别

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

事务的隔离级别就是通过锁的机制来实现,只不过隐藏了加锁细节 在表锁中我们读写是阻塞的,基于提升并发性能的考虑,MVCC一般读写是不阻塞的(所以说MVCC很多情况下避免了加锁的操作)

MVCC实现的读写不阻塞正如其名:多版本并发控制--->通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot),并用这个快照来提供一定级别(语句级或事务级)的一致性读取。从用户的角度来看,好像是数据库可以提供同一数据的多个版本。

5.1 快照有两个级别

  1. 语句级:针对于Read committed隔离级别
  2. 事务级别:针对于Repeatable read隔离级别

5.2 事务的隔离级别

我们在初学的时候已经知道,事务的隔离级别有4种:

  1. Read uncommitted 会出现脏读,不可重复读,幻读
  2. Read committed 会出现不可重复读,幻读
  3. Repeatable read 会出现幻读(但在Mysql实现的Repeatable read配合gap锁不会出现幻读!)
  4. Serializable 串行,避免以上的情况!

5.2.1 Read uncommitted 会出现-->脏读:一个事务读取到另外一个事务未提交的数据

例子:A向B转账,A执行了转账语句,但A还没有提交事务,B读取数据,发现自己账户钱变多了!B跟A说,我已经收到钱了。A回滚事务【rollback】,等B再查看账户的钱时,发现钱并没有多。 出现脏读的原因是因为在读的时候没有加读锁,导致可以读取出还没释放锁的记录。

Read uncommitted过程:

事务A读取记录(没有加任何的锁)
事务B修改记录(此时加了写锁,并且还没有commit-->也就没有释放掉写锁)
事务A再次读取记录(此时因为事务A在读取时没有加任何锁,所以可以读取到事务B还没提交的(没释放掉写锁)的记录

Read committed避免脏读的做法其实很简单:

在读取的时候生成一个版本号,直到事务其他commit被修改了之后,才会有新的版本号

Read committed过程:

事务A读取了记录(生成版本号)
事务B修改了记录(此时加了写锁)
事务A再读取的时候,是依据最新的版本号来读取的(当事务B执行commit了之后,会生成一个新的版本号),如果事务B还没有commit,那事务A读取的还是之前版本号的数据。

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

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

上面也说了,Read committed是语句级别的快照!每次读取的都是当前最新的版本!

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

呃...如果还是不太清楚,我们来看看InnoDB的MVCC是怎么样的吧(摘抄《高性能MySQL》)再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦 至于虚读(幻读):是指在一个事务内读取到了别的事务插入的数据,导致前后读取不一致。

注:和不可重复读类似,但虚读(幻读)会读到其他事务的插入的数据,导致前后读取不一致 MySQL的Repeatable read隔离级别加上GAP间隙锁已经处理了幻读了。

6. 乐观锁和悲观锁

无论是Read committed还是Repeatable read隔离级别,都是为了解决读写冲突的问题。

单纯在Repeatable read隔离级别下我们来考虑一个问题: 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

此时,用户李四的操作就丢失掉了:

丢失更新:一个事务的更新覆盖了其它事务的更新结果。 (ps:暂时没有想到比较好的例子来说明更新丢失的问题,虽然上面的例子也是更新丢失,但一定程度上是可接受的..不知道有没有人能想到不可接受的更新丢失例子呢...)

解决的方法:

使用Serializable隔离级别,事务是串行执行的!

  • 乐观锁是一种思想,具体实现是,表中有一个版本字段,第一次读的时候,获取到这个字段。处理完业务逻辑开始更新的时候,需要再次查看该字段的值是否和第一次的一样。如果一样更新,反之拒绝。之所以叫乐观,因为这个模式没有从数据库加锁,等到更新的时候再判断是否可以更新。
  • 悲观锁是数据库层面加锁,都会阻塞去等待锁。

6.1 悲观锁

所以,按照上面的例子。我们使用悲观锁的话其实很简单(手动加行锁就行了):

select * from xxxx for update

在select 语句后边加了 for update相当于加了排它锁(写锁),加了写锁以后,其他的事务就不能对它修改了!需要等待当前事务修改完之后才可以修改.

也就是说,如果张三使用select ... for update,李四就无法对该条记录修改了~

6.2 乐观锁

乐观锁不是数据库层面上的锁,是需要自己手动去加的锁。一般我们添加一个版本字段来实现:

具体过程是这样的:

张三 select * from table --->会查询出记录出来,同时会有一个version字段 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

李四select * from table --->会查询出记录出来,同时会有一个version字段 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

李四对这条记录做修改:update A set Name=lisi,version=version+1 where ID=#{id} and version=#{version},判断之前查询到的version与现在的数据的version进行比较,同时会更新version字段

此时数据库记录如下:

再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

张三也对这条记录修改: update A set Name=lisi,version=version+1 where ID=#{id} and version=#{version},但失败了!因为当前数据库中的版本跟查询出来的版本不一致!

再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦

7. 间隙锁 GAP

当我们用范围条件检索数据而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合范围条件的已有数据记录的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”。InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁。

值得注意的是:间隙锁只会在Repeatable read隔离级别下使用~

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

Select * from emp where empid > 100 for update; 上面是一个范围查询,InnoDB不仅会对符合条件的empid值为101的记录加锁,也会对empid大于101(这些记录并不存在)的“间隙”加锁。

InnoDB使用间隙锁的目的有两个:

  1. 为了防止幻读(上面也说了,Repeatable read隔离级别下再通过GAP锁即可避免了幻读)满足恢复和复制的需要
  2. MySQL的恢复机制要求:在一个事务未提交前,其他并发事务不能插入满足其锁定条件的任何记录,也就是不允许出现幻读

8. 死锁

并发的问题就少不了死锁,在MySQL中同样会存在死锁的问题。

但一般来说MySQL通过回滚帮我们解决了不少死锁的问题了,但死锁是无法完全避免的,可以通过以下的经验参考,来尽可能少遇到死锁:

  1. 以固定的顺序访问表和行。比如对两个job批量更新的情形,简单方法是对id列表先排序,后执行,这样就避免了交叉等待锁的情形;将两个事务的sql顺序调整为一致,也能避免死锁。
  2. 大事务拆小。大事务更倾向于死锁,如果业务允许,将大事务拆小。
  3. 在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率。
  4. 降低隔离级别。如果业务允许,将隔离级别调低也是较好的选择,比如将隔离级别从RR调整为RC,可以避免掉很多因为gap锁造成的死锁。
  5. 为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁,死锁的概率大大增大。

9. 锁的总结

上面说了一大堆关于MySQL数据库锁的东西,现在来简单总结一下。

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

  • 在MyISAM存储引擎中,当执行SQL语句的时候是自动加的。
  • 在InnoDB存储引擎中,如果没有使用索引,表锁也是自动加的。
  • 现在我们大多数使用MySQL都是使用InnoDB,InnoDB支持行锁:
  1. 共享锁--读锁--S锁
  2. 排它锁--写锁--X锁

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

  1. 读锁、共享锁(S):SELECT * FROM table\_name WHERE ... LOCK IN SHARE MODE
  2. 写锁、排他锁(X):SELECT * FROM table\_name WHERE ... FOR UPDATE

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

InnoDB实现的Repeatable read隔离级别配合GAP间隙锁已经避免了幻读!

  1. 乐观锁其实是一种思想,正如其名:认为不会锁定的情况下去更新数据,如果发现不对劲,才不更新(回滚)。在数据库中往往添加一个version字段来实现。
  2. 悲观锁用的就是数据库的行锁,认为数据库会发生并发冲突,直接上来就把数据锁住,其他事务不能修改,直至提交了当前事务。

四、MySQL和PostgreSQL对比

通篇看下来你会发现MySQL和PostgreSQL对于并发控制的路子不太一样。这里稍微总结一下: 再过60分钟你就能了解mysql中的隔离级别、锁、MVCC啦 在MySQL中,很多开发者倾向于自己在默认隔离级别之外手工加锁。而PostgreSQL则建议尽量避免直接加锁,因为其Repeatable Read和Serializable的实现已经相当完善,开发者没必要自找麻烦。

转载自:https://juejin.cn/post/7245854874196443195
评论
请登录