提到事务,大家都不陌生,在使用数据库的时候,我们总会提到事务,最经典的例子就是转帐,比如小王的银行卡上有一百块,要把这一百块转账,转账过程中的一系列操作,比如查询余额、扣减资金、增加资金、更新余额等,这些操作必须保证是一体的,不然等查询余额之后,在扣除资金之前,完全可以借着这个时间再查一次,然后将这个钱转给另外一个人,这样不就乱套了。

事务的概念各位都不陌生,简单来说,事务就是要保证一组数据库操作,要么全部成功,要么全部失败。MySQL数据库的事务支持是在引擎层实现的。MySQL是一个支持多引擎的系统,但是不是所有的引擎都支持事务,只有InnoDB支持事务。

隔离性与隔离级别

大家都都知道事务的四种属性ACID,今天我们就说说其中的 I,也就是隔离性。

数据库多个事务同时执行的时候,就会出现脏读(dirty read)、幻读(phantom read)、不可重复读 (non-repeatable read)等问题,为了解决这些问题,就有了隔离级别的概念。

事务的隔离等级越高,效率就会越低,很多时候我们就在数据准确和效率之间找平衡点。SQL标准的事务隔离级别包括:读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(serializable)。可能很多人已经对这几个概念很熟悉,这里就简单介绍一下:

  • 读未提交:一个事务还没提交时,它做的变更就能被其他事务看到。
  • 读提交:一个事务只有在提交之后,其它事务才能看到它做的变更。
  • 可重复读:一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的,在可重复读隔离级别下,未提交变更对其它事务也是不可见的。
  • 串行化:顾名思义是对同一行记录,“写”会加“写锁”,“读”会加“读锁”,当读写锁冲突的时候,后访问的事务必须等前一个事务执行完成才能继续执行。

下边通过一个例子来说明几个隔离级别,先准备一张表T,其中一行的值为1 ,按照时间顺序执行两个事务的行为:

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

下边我们来看看不同的隔离级别下,事务A的各个查询的结果,也就是V1,V2,V3的返回值分别是什么。

  • 隔离级别是“读未提交”,则V1的值是2,这个时候虽然事务B还没有提交,但是结果已经被事务A看到了,所以V2,V3也都是2.
  • 隔离级别是“读提交”,则V1的值是1,查询V2的时候事务B已经提交,所以事务B的更新事务A是可以看到的,所以V2是2,V3也是2。
  • 隔离级别是“可重复读”,则V1、V2是1,V3是2,为什么V2还是1,是因为事务在执行期看到的数据前后必须是一致的。
  • 隔离级别是“串行化”,在事务B执行将1改为2的时候,会被锁住,等事务A执行完提交后,事务B才可以继续执行,所以从事务A的角度来看,V1、V2值是1,V3的值是2.

在实现上,数据库里面会创建一个视图,访问的时候以视图的逻辑为准,在“可重复读”隔离级别下,这个视图是在事务启动时创建的,整个事务存在期间都用整个视图。在“读提交“隔离级别下,这个视图是在每个SQL语句开始执行的时候创建的。”读未提交“隔离级别下直接返回记录上的最新值,没有视图概念。而”串行化“隔离级别下直接用加锁的方式来避免并行访问。

我们可以根据需要来修改MySQL的隔离级别,如我们要将MySQL的隔离级别设置为”读提交“,配置的方式是,将启动参数transaction-isolation的值设置成READ-COMMITTED,可以用show variables来查看当前的值。


mysql> show variables like 'transaction_isolation';

+-----------------------+----------------+

| Variable_name | Value |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

+-----------------------+----------------+

事务隔离的实现

上边我们了解了事务的隔离级别,我们再来看看事务隔离具体是怎么实现的。这里我们来详细说说”可重复读“,在MySQL中,实际上每条记录在更新的时候都会同时记录一条回滚操作,记录上的最新值,通过回滚的方式都可以得到前一个状态的值。

假设一个值从1被依次改成了2、3、4,在回滚日志(undo log)里就会有类似下边的记录。

当前值是4,但是在查询这条记录的时候,不同时刻启动的事务会有不同的read-view,如图中看到的,在视图A、B、C里面,这个记录的值分别是1、2、4,同一条记录在系统中可以存在多个版本,就是数据库的多版本并发控制(MVCC)。对于read-viewA,要想得到1,就必须将当前值依次执行图中所有的回滚操作得到。

这个时候你会发现,即使现在另外一个事务正在将4改为3,这个事务跟read-viewA、B、C对应的事务是不会冲突的。

回滚日志的保留时间,在不需要的时候才会删除,系统判断,没有其他事务线程还在使用当前版本的undo的时候,purge进程进行回收。

基于上边的说明,我们来讨论一下大佬们常说的尽量不使用长事务是为什么?

长事务意味着系统里面会存在很老的事务视图,由于这些事务随时可能访问数据库里面的任何数据,所以这个事务提交之前,数据库里面它可能用到的回滚记录都必须保留,这就导致了大量占用内存。在MySQL5.5以前的版本,回滚日志是和数据字典一起放在ibdata文件里的,即使长事务提交,回滚段被清理,文件也不会变小,最终往往为了清理回滚段而重建整个库。除了影响回滚段,长事务还会占用锁资源,也有可能拖垮整个库。

事务的启动方式

长事务的潜在风险我们上边已经聊过了,建议是尽可能的避免,其实很多长事务,并不是有意使用,都是被误用所致,下边我们聊聊MySQL的事务启动方式:

  1. 显示启动事务语句,begin或者start transaction。配套的提交语句是commit,回滚语句是rollback。
  2. set autocommit = 0,这个命令会将这个线程的自动提交关掉,意味着如果你只执行一个select语句,这个事务就启动了,而且不会自动提交,这个事务会一直持续存在直到你主动执行commit或者rollback语句,或者断开连接。

有一些客户端连接框架会默认连接成功后执行一个set autocommit = 0命令,这就导致了接下来的查询都在事务中,如果是长连接,就导致了意外的长事务。因此,建议使用set autocommit=1,通过显式语句的方式来启动事务。

有的朋友会纠结”多一次交互“的问题,对于一个频繁使用事务的业务,第二种方式,每个事务在开始时都不需要主动执行一次”begin“,减少了语句的交互次数,如果你也有这个顾虑,可以使用commit work and chain语法。

autocommit为1的情况下,用begin显式启动事务,如果执行commit,则提交事务,如果执行commit work and chain,则是提交事务并开启下一个事务,减少了begin的开销。同时从程序开发的角度明确知道每个语句是否处于事务中。

你可以在 information_schema 库的 innodb_trx 这个表中查询长事务,比如下面这个语句,用于查找持续时间超过 60s 的事务。

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

最后,我们可以通过尝试回答以下几个问题,来检查自己的掌握程度;

1.事务的概念是什么?
2.mysql的事务隔离级别读未提交, 读已提交, 可重复读, 串行各是什么意思?
3.读已提交, 可重复读是怎么通过视图构建实现的?
4.可重复读的使用场景举例? 对账的时候应该很有用?
5.事务隔离是怎么通过read-view(读视图)实现的?
6.并发版本控制(MCVV)的概念是什么, 是怎么实现的?
7.使用长事务的弊病? 为什么使用常事务可能拖垮整个库?
8.事务的启动方式有哪几种?
9.commit work and chain的语法是做什么用的?
10.怎么查询各个表中的长事务?
11.如何避免长事务的出现?

文章来源于互联网:MySQL的事务隔离级别和长连接,看这一篇就够了

发表评论