MySql事务及原理详解
事务是数据库最小工作单元,它的操作是不可以被分割的原子操作,是保证数据一致性的重要手段之一。本文将通过基本概念、特性、隔离级别以及实现原理,带领大家熟悉MySql中的事务。在MySql中,常见支持事务的存储引擎包括innoDB,NDB等,而另外一个常用的存储引擎MyISAM是不支持事务的,本文主要针对innoDB进行分析。
1 事务基础
首先来看一下事务的4大特性ACID:
- 原子性(Atomicity):一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。
- 一致性(Consistent):一方面,在事务开始之前和事务结束以后,数据库的完整性没有被破坏;另一方面,写入的数据必须完全符合所有的预设规则。
- 隔离性(Isolation):不同的会话或线程,操作数据库的时候可能产生多个事务。如果同时操作一张表或同一行数据,必然产生并发或干扰操作。隔离性要求事务间对表或数据操作是透明的,互相不存在干扰的,通过这种方式保证一致性。
- 持久性(Durable):事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
那么,数据库中什么时候会出现事务呢?在MySql中,事务的提交存在两种方式,自动提交与手动提交,默认已经开启了自动提交。
可以使用指令查看是否开启自动提交:
show variables like 'autocommit';
当变量autocommit的值为ON时,代表自动提交开启,改为OFF则变为手动提交。在手动提交模式下,可以使用下面两种指令开启事务:
start transaction;
begin;
这两种指令都是显示开启一个事务,标识事务的开始,具有相同的作用。
结束事务的方式也有两种,事务确认提交:
commit;
事务回滚:
rollback;
当 commit或 rollback语句执行后,事务会自动关闭。
2 事务并发问题
介绍完事务的基本概念,我们通过几个示例来看一下,事务并发会带来什么问题。
1、脏读:
脏读表示一个事务在处理过程中,读取到了其他事务未进行提交的数据。这种数据被称之为脏数据,依据脏数据进行的操作可能是不正确的。
如上图所示,在事务A中读取到了事务B未提交的数据。那么如果事务B之后进行了回滚,那么事务A则都到了脏数据。
2、不可重复读:
不可重复读是指在一个事务范围内,多次进行相同的查询,却得到不同结果。也就是说多次读取同一条记录,但记录中的某些列的值被修改过。
与脏读不同的是,脏读是读取到了其他事务未提交的数据,而不可重复读是读取了其他事务提交的数据。
3、幻读:
幻读是指当事务不是独立执行时发生的一种现象,幻读主要是说多次读取一个范围内的记录,包括直接查询所有记录结果或聚合统计,发现了结果数量的不一致性(包括结果的增多或减少)。
与不可重复读相同,也是一个事务读取到了其他事务已提交的数据。但是不同的是,查询的结果集发生了数量的变化。
以上数据库的事务并发三大问题其实都是数据库读一致性的问题,必须由数据库提供一定的事务隔离机制来解决。
3 事务隔离级别
看一下SQL92 ANSI/ISO定义的事务的四种隔离级别:
- Read Uncommitted(读未提交):事务未提交的数据对其他事务也是可见的,会出现脏读
- Read Committed(读已提交):一个事务开始后,只能看到已提交的事务所做的修改,会出现不可重复读
- Repeatable Read(可重复读):在同一个事务中多次读取同样的数据结果是一致的,这种隔离级别未定义解决幻读的问题
- Serializable(串行化):最高的隔离级别,通过强制事务的串行执行
那么这几个级别能解决什么问题呢:
- 在读未提交级别,不能解决任何事务并发的问题
- 在读已提交级别,能够解决脏读问题
- 在可重复读级别,能够解决不可重复读问题
- 在串行化级别,能够解决所有问题,但是相应的会降低数据库事务的并发度,降低性能
以表格的形式直观的看一下:
需要注意的是,innoDB默认的事务隔离级别是第3级的可重复读,但是innoDB在这一级别,在部分场景下规避了幻读的问题,接下来看一下两种解决原理。
- Lock Based Concurrency Control(LBCC)
- 基于锁的并发控制
LBCC在读取数据前,对其加锁,阻止其他事务对数据进行修改。它对应了4种隔离级别中级别最高的串行化隔离级别。在这个级别上,因为锁的粒度过大,会导致性能的下降,因此提出了比LBCC性能更优越的方法MVCC。
- Multi version Concurrency controll (MVCC)
- 基于快照(多版本)并发控制
MVCC是一种用来解决读写冲突的无锁并发控制,innoDB内部使用了该机制来实现了一致性非阻塞读,大大提高了并发读写速率,写操作不影响到读操作,并且读到的是一个数据的快照(snapshot)版本。
其基本实现原理是为事务分配单向增长的时间戳,生成一个数据请求时间点的一致性数据快照,快照版本与事务时间戳关联,并用这个快照来提供一定级别的一致性读取(包括语句级或事务级)。
在看MVCC的具体实现之前,需要了解一下MySql中3个隐式字段:
- DB_TRX_ID:创建版本号,是最近修改事务的ID,自动递增。记录了插入或更新行的最后一个事务的事务ID
- DB_ROLL_PTR:回滚指针(或删除指针),配合undo log,指向这条记录的上一个版本
- DB_ROW_ID:隐藏的行ID,如果数据表没有设置主键,会以它产生聚簇索引
MVCC的多版本并发控制,实现的主要原理就是依赖这3个隐式字段实现的,其核心思想就是:
- 只能查找创建时间小于等于当前事务ID的行
- 只能查找删除时间大于等于当前事务ID的行,或未删除的行
基于这两点,我们根据实例进行分析,还是以item表作为示例,暂时先不看price字段。两个用户自定义字段和三个隐式字段如下格式:
事务2进行查询时,事务3插入数据,插入结束后事务2继续进行查询:
事务3中,beer的创建版本为3,而事务2只能查询到本事务的修改,和在第一次查询前已经提交的事务的修改,因此版本3的数据不满足条件。
在上面的基础上,新建事务4删除数据,再在事务2中进行查询:
事务4中,将id为2的数据的删除版本号写为4,但是在事务2中仍然可以读到删除版本号大于当前版本的数据,因此还能读到id为2的数据。
在上面的基础上,新建事务5进行数据update操作,再在事务2中进行查询:
事务2仍然只能查到本事务的修改和第一次查询前已经提交的事务的修改,而事务5中更新的id为1的数据,创建版本大于事务2,不满足条件,无法被查找。
上面只对MVCC使用的两大规则进行了简化的演示,除此之外,很多情况下MVCC是与数据库的锁结合使用的,例如当前读就会使用锁,而快照读使用MVCC。通过以上例子,希望能够帮助大家更好的理解MqSql事务的工作机制。
本文转载自微信公众号「码农参上」