MySQL架构(三)-事务

503 阅读19分钟

1.什么是数据库的事务?

事务的应用场景

在项目里面,在方法上加注解或者配置切面。 比如下单,会操作订单表,资金表,物流表等等,这个时候我们需要让这些操作都 在一个事务里面完成。当一个业务流程涉及多个表的操作的时候,我们希望它们要么是 全部成功的,要么都不成功,这个时候我们会启用事务。

在金融的系统里面事务配置是很常见的,比如行内转账的这种操作,如果我们把它简单地理解为一个账户的余额增加,另一个账户的余额减少的情况(当然实际上要比这 复杂),那么这两个动作一定是同时成功或者同时失败的,否则就会造成银行的会计科目不平衡

事务的定义

什么是事务?
维基百科的定义:事务是数据库管理系统(DBMS)执行过程中的一个逻辑单位,由 一个有限的数据库操作序列构成。
这里面有两个关键点,

  1. 它是数据库最小的工作单元,是不可以再分的。
  2. 它可能包含了一个或者一系列的DML语句,包括insert delete update。(单条DDL(create drop)和DCL(grant revoke)也会有事务)

存储引擎对于事务的支持

InnoDB支持事务,这个也是它成为默认的存储引擎的一个重要原因

事务的四大特性

事务的四大特性:ACID。

  1. 原子性,Atomicity,也就是我们刚才说的不可再分,也就意味着我们对数 据库的一系列的操作,要么都是成功,要么都是失败,不可能出现部分成功或者部分失 败的情况。比如说:一个账户的余额减少,对应一个账户的增加,这两个一定是同时成功或者同时失败的。
    原子性,在InnoDB里面是通过undolog来实现的,它记录了数据修改之前的值(逻辑日志),一旦发生异常,就可以用undo log来实现回滚操作。
  2. 一致性,consistent,指的是数据库的完整性约束没有被破坏,事务执行的前后都是合法的数据状态。比如主键必须是唯一的,字段长度符合要求。除了数据库自身的完整性约束,还有一个是用户自定义的完整性。 比如说:转账不可能出现一个用户转了1000元,而另一个用户只收到了500元
  3. 隔离性,Isolation,我们有了事务的定义以后,在数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据,必然会产生一些并发或者干扰的操作,那么我们对隔离性的定义,就是这些很多个的事务,对表或者行的并发操作,应该是透明的,互相不干扰的。通过这种方式,我们最终也是保证业务数据的一致性
  4. 持久性,Durable,我们对数据库的任意的操作,增删改,只要事务提交成功,那么结果就是永久性的,不可能因为我们系统宕机或者重启了数据库的服务器,它又恢复到原来的状态了。这个就是事务的持久性。
    持久性是通过redolog和doublewrite双写缓冲来实现的,我们操作数据的时候会先写到内存的buffer pool里面,同时记录redo log,如果在刷盘之前出现异常,在重启后就可以读取redo log的内容,写入到磁盘,保证数据的持久性

原子性,隔离性,持久性,最后都是为了实现一致性。

数据库什么时候会出现事务

无论是我们在 Navicat 的这种工具里面去操作,还是在我们的 Java 代码里面通过 API 去操作,还是加上@Transactional 的注解或者 AOP 配置,其实最终都是发送一个 指令到数据库去执行,Java的JDBC只不过是把这些命令封装起来了。

MySQL默认的每一条语句都自动开启一个事务也可以通过手动开启一个事务

手动开启事务也有几种方式,一种是用begin;一种是用start transaction。

结束事务有三种方式

  1. 就是提交一个事务,commit;
  2. 就是rollback,回滚的时候,事务也会结束。
  3. 客户端的连接断开的时候,事务也会结束。

事务并发会带来什么问题?

脏读

我们有两个事务,一个是Transaction A,一个是Transaction B,在第一个事务里 面,它首先通过一个where id=1的条件查询一条数据,返回name=Ada,age=16的 这条数据。然后第二个事务,它同样地是去操作id=1的这行数据,它通过一个update 的语句,把这行id=1的数据的age改成了18,但是注意,它没有提交。

这个时候,在第一个事务里面,它再次去执行相同的查询操作,发现数据发生了变 化,获取到的数据age变成了18。那么,这种在一个事务里面,由于其他的时候修改了 数据并且没有提交,而导致了前后两次读取数据不一致的情况,这种事务并发的问题,叫做脏读。

不可重复读

同样是两个事务,第一个事务通过id=1查询到了一条数据。然后在第二个事务里面 执行了一个update操作,这里大家注意一下,执行了update以后它通过一个commit 提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不 一致的情况,就像这里,age到底是等于16 还是18。

这种一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情 况,我们把它叫做不可重复读。

幻读

在第一个事务里面我们执行了一个范围查询,这个时候满足条件的数据只有一条。 在第二个事务里面,它插入了一行数据,并且提交了。重点:插入了一行数据。在第一 个事务里面再去查询的时候,它发现多了一行数据。

一个事务前后两次读取数据数据不一致,是由于其他事务插入数据造成的,这种情 况我们把它叫做幻读。

不可重复读是修改或者删除,幻读是插入。

我们刚才讲了事务并发带来的三大问题,现在来给大家总结一下。无论是脏读,还是不可重复读,还是幻读,它们都是数据库的读一致性的问题,都是在一个事务面前后两次读取出现了不一致的情况。

读一致性的问题,必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭,基本的设施和卫生保证都是饭店提供的。那么我们使用数据库,隔离性的问题也必须由数据库帮助我们来解决。

隔离级别

MySQL InnoDB 对隔离级别的支持

在MySQLInnoDB里面,不需要使用串行化的隔离级别去解决所有问题。那我们来看一下MySQL InnoDB里面对数据库事务隔离级别的支持程度是什么样的。

2.InnoDB解决事务问题

MVCC

如果要让一个事务前后两次读取的数据保持一致,那么我们可以在修改数据的时候给它建立一个备份或者叫快照,后面再来读取这个快照就行了。这种方案我们叫做多版本的并发控制 Multi Version Concurrency Control(MVCC)。

MVCC的核心思想是: 我可以查到在我这个事务开始之前已经存在的数据,即使它在后面被修改或者删除了。在我这个事务之后新增的数据,我是查不到的。

InnoDB为每行记录都实现了两个隐藏字段:

DB_TRX_ID,6字节:插入或更新行的最后一个事务的事务ID,事务编号是自动递 增的(我们把它理解为创建版本号,在数据新增或者修改为新数据的时候,记录当前事 务ID)。

DB_ROLL_PTR,7字节:回滚指针(我们把它理解为删除版本号,数据被删除或记 录为旧数据的时候,记录当前事务ID)。

我们把这两个事务ID理解为版本号。

通过上图演示我们能看到,通过版本号的控制,无论其他事务是插入、修改、删除,第一个事务查询到的数据都没有变化。

LBCC

我既然要保证前后两次读取数据一致,那么我读取数据的时候,锁定我要操作的数据,不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制LockBased Concurrency Control(LBCC)。

如果仅仅是基于锁来实现事务隔离,一个事务读取的时候不允许其他时候修改,那就意味着不支持并发的读写操作,而我们的大多数应用都是读多写少的,这样会极大地影响操作数据的效率。

3.MySQL InnoDB 锁的基本类型

官网把锁分成了8 类。所以我们把前面的两个行级别的锁(Shared and ExclusiveLocks),和两个表级别的锁(Intention Locks)称为锁的基本模式。

后面三个RecordLocks、GapLocks、Next-KeyLocks,我们把它们叫做锁的算法,也就是分别在什么情况下锁定什么范围。

锁的粒度

我们讲到 InnoDB 里面既有行级别的锁,又有表级别的锁,我们先来分析一下这两种锁定粒度的一些差异。

表锁,顾名思义,是锁住一张表;行锁就是锁住表里面的一行数据。锁定粒度,表 锁肯定是大于行锁的。

那么加锁效率,表锁应该是大于行锁还是小于行锁呢?大于。为什么?表锁只需要 直接锁住这张表就行了,而行锁,还需要在表里面去检索这一行数据,所以表锁的加锁 效率更高。

第二个冲突的概率?表锁的冲突概率比行锁大,还是小?

大于,因为当我们锁住一张表的时候,其他任何一个事务都不能操作这张表。但是 我们锁住了表里面的一行数据的时候,其他的事务还可以来操作表里面的其他没有被锁 定的行,所以表锁的冲突概率更大。

表锁的冲突概率更大,所以并发性能更低,这里并发性能就是小于。

InnoDB里面我们知道它既支持表锁又支持行锁, 另一个常用的存储引擎MyISAM支 持什么粒度的锁?这是第一个问题。第二个就是InnoDB 已经支持行锁了,那么它也可 以通过把表里面的每一行都锁住来实现表锁,为什么还要提供表锁呢?
要搞清楚这个问题,我们就要来了解一下 InnoDB 里面的基本的锁的模式(lock mode),这里面有两个行锁和两个表锁。

共享锁

第一个行级别的锁就是我们在官网看到的 Shared Locks (共享锁),我们获取了 一行数据的读锁以后,可以用来读取数据,所以它也叫做读锁,注意不要在加上了读锁以后去写数据,不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。

释放锁有两种方式,只要事务结束,锁就会自动事务,包括提交事务和结束事务

排他锁

第二个行级别的锁叫做Exclusive Locks(排它锁),它是用来操作数据的,所以又叫做写锁。只要一个事务获取了一行数据的排它锁,其他的事务就不能再获取这一行数据的共享锁和排它锁。

排它锁的加锁方式有两种,第一种是自动加排他锁。我们在操作数据的时候,包括增删改,都会默认加上一个排它锁。

还有一种是手工加锁,我们用一个FORUPDATE给一行数据加上一个排它锁,这个 无论是在我们的代码里面还是操作数据的工具里面,都比较常用。

这个是两个行锁,接下来就是两个表锁

意向锁

意向锁是什么呢?我们好像从来没有听过,也从来没有使用过,其实他们是由数据 库自己维护的。

也就是说,当我们给一行数据加上共享锁之前,数据库会自动在这张表上面加一个 意向共享锁。

当我们给一行数据加上排他锁之前,数据库会自动在这张表上面加一个意向排他锁。 反过来说:

如果一张表上面至少有一个意向共享锁,说明有其他的事务给其中的某些数据行加 上了共享锁。

如果一张表上面至少有一个意向排他锁,说明有其他的事务给其中的某些数据行加 上了排他锁。 那么这两个表级别的锁存在的意义是什么呢?第一个,我们有了表级别的锁,在 InnoDB里面就可以支持更多粒度的锁。它的第二个作用,我们想一下,如果说没有意向 锁的话,当我们准备给一张表加上表锁的时候,我们首先要做什么?是不是必须先要去 判断有没其他的事务锁定了其中了某些行?如果有的话,肯定不能加上表锁。那么这个 时候我们就要去扫描整张表才能确定能不能成功加上一个表锁,如果数据量特别大,比 如有上千万的数据的时候,加表锁的效率是不是很低?

但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁,如 果有,就直接返回失败。如果没有,就可以加锁成功。所以 InnoDB 里面的表锁,我们 可以把它理解成一个标志。就像火车上厕所有没有人使用的灯,是用来提高加锁的效率 的。

以上就是MySQL里面的4种基本的锁的模式,或者叫做锁的类型。

到这里我们要思考两个问题,首先,锁的作用是什么?它跟Java里面的锁是一样的, 是为了解决资源竞争的问题,Java里面的资源是对象,数据库的资源就是数据表或者数 据行。

所以锁是用来解决事务对数据的并发访问的问题的。

4.行锁的原理

  • 先提出一个问题,行锁到底锁住了这一行数据,还是锁住了这一个字段,还是锁住了别的什么东西呢?

没有索引的表(假设锁住记录)

在第一个事务里面,我们通过where id =1 锁住第一行数据。

在第二个事务里面,我们尝试给id=3的这一行数据加锁。

结果失败

我们再来操作一条不存在的数据,插入id=5。它也被阻塞了。实际上这里整张表都 被锁住了。所以,我们的第一个猜想被推翻了,InnoDB的锁锁住的应该不是Record

有主键索引的表

我们看一下t2的表结构。字段是一样的,不同的地方是id上创建了一个主键索引。 里面的数据是1、4、7、10。 第一种情况,使用相同的id值去加锁,冲突;使用不同的id加锁,可以加锁成功。 那么,既然不是锁定一行数据,有没有可能是锁住了id的这个字段呢?

唯一索引(假设锁住字段)

我们看一下 t3的表结构。字段还是一样的, id上创建了一个主键索引,name上 创建了一个唯一索引。里面的数据是1、4、7、10。

在第一个事务里面,我们通过name字段去锁定值是4的这行数据。

在第二个事务里面,尝试获取一样的排它锁,肯定是失败的,这个不用怀疑。

在这里我们怀疑InnoDB锁住的是字段,所以这次我换一个字段,用id=4去给这行 数据加锁。

很遗憾,又被阻塞了,说明锁住的是字段的这个推测也是错的,否则就不会出现第 一个事务锁住了name,第二个字段锁住id失败的情况。

既然锁住的不是record,也不是column, InnoDB里面锁住的到底是什么呢?在这 三个案例里面,我们要去分析一下他们的差异在哪里,也就是这三张表的结构,是什么 区别导致了加锁的行为的差异?其实答案就是索引。 InnoDB的行锁,就是通过锁住索引来实现的。

  • 为什么表里面没有索引的时候,锁住一行数据会导致锁表? 或者说,如果锁住的是索引,一张表没有索引怎么办? 所以,一张表有没有可能没有索引?
  1. 如果我们定义了主键(PRIMARYKEY),那么 InnoDB 会选择主键作为聚集索引。
  2. 如果没有显式定义主键,则 InnoDB 会选择第一个不包含有 NULL 值的唯一索 引作为主键索引。
  3. 如果也没有这样的唯一索引,则 InnoDB 会选择内置 6 字节长的 ROWID 作 为隐藏的聚集索引,它会随着行记录的写入而主键递增。 所以,为什么锁表,是因为查询没有使用索引,会进行全表扫描,然后把每一个隐藏的聚集索引都锁住了。
  • 为什么通过唯一索引给数据行加锁,主键索引也会被锁住?
  1. 在辅助索引里面, 索引存储的是二级索引和主键的值。 比如name=4,存储的是name 的索引和主键id的值4。

  2. 而主键索引里面除了索引之外,还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候,它跟我们检索数据的步骤是一样的,会通过主键值找到主键索引,然后也锁定。

所以说在进行行锁的时候,如果用到了主键索引那么锁住的就是主键,如果用到了普通索引锁住的就是普通索引和主键,如果没有用到索引。那么锁住就是全表

现在我们已经搞清楚4个锁的基本类型和锁的原理了,在官网上,还有3种锁,我们把它理解为锁的算法。我们也来看下InnoDB在什么时候分别锁住什么范围。

5.锁的算法

记录锁

当我们对于唯一性的索引(包括唯一索引和主键索引)使用等值查询,精准匹配到一条记录的时候,这个时候使用的就是记录锁。

间隙锁

第二种情况,当我们查询的记录不存在,没有命中任何一个record,无论是用等值 查询还是范围查询的时候,它使用的都是间隙锁。 举个例子,where id >4 and id <7,where id = 6。

临建锁

当我们使用了范围查询,不仅仅命中了Record记录,还包含了 Gap间隙,在这种情况下我们使用的就是临键锁,它是MySQL里面默认的行锁算法,相当于记录锁加上间隙锁。

比如我们使用>5 <9, 它包含了记录不存在的区间,也包含了一个Record 7。

现在搞明白了为什么innodb能够解决几乎所有的事务问题

使用了MVCC+锁的机制

6.事务隔离级别怎么选择

RU 和 Serializable 肯定不能用。为什么有些公司要用 RC,或者说网上有些文章推 荐有RC?

RC和RR主要有几个区别:

  1. RR的间隙锁会导致锁定范围的扩大。
  2. 条件列未使用到索引,RR锁表,RC锁行。
  3. RC的“半一致性”(semi-consistent)读可以增加update操作的并发性。

在RC中,一个update语句,如果读到一行已经加锁的记录,此时InnoDB返回记 录最近提交的版本,由MySQL上层判断此版本是否满足 update的where条件。若满 足(需要更新),则MySQL会重新发起一次读操作,此时会读取行的最新版本(并加锁)。 实际上,如果能够正确地使用锁(避免不使用索引去枷锁),只锁定需要的数据, 用默认的RR级别就可以了。

在我们使用锁的时候,有一个问题是需要注意和避免的,我们知道,排它锁有互斥 的特性。一个事务或者说一个线程持有锁的时候,会阻止其他的线程获取锁,这个时候 会造成阻塞等待,如果循环等待,会有可能造成死锁。

7.死锁

那么死锁需要满足什么条件?死锁的产生条件: 因为锁本身是互斥的

  1. 同一时刻只能有一个事务持有这把锁
  2. 其他的事务需要在这个事务释放锁之后才能获取锁,而不可以强行剥夺
  3. 当多个事务形成等 待环路的时候,即发生死锁。

死锁的避免

  1. 在程序中,操作多张表时,尽量以相同的顺序来访问(避免形成等待环路);
  2. 批量操作单张表数据的时候,先对数据进行排序(避免形成等待环路);
  3. 申请足够级别的锁,如果要操作数据,就申请排它锁;
  4. 尽量使用索引访问数据,避免没有where条件的操作,避免锁表;
  5. 如果可以,大事务化成小事务;
  6. 使用等值查询而不是范围查询查询数据,命中记录,避免间隙锁对并发的影响。