mysql事务
Posted zsql
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql事务相关的知识,希望对你有一定的参考价值。
本篇文章主要从事务的分类,操作,事务隔离级别几个方面进行阐述。
一、概述
事务是数据库系统区别文件系统的一个重要特性。
事务会把数据库从一种状态转为另一种状态。要么都修改,要么都不改。
事务可以是一个简单的sql,也可以是一个复杂的sql,事务是访问并更新数据库中各个数据项的一个程序执行单元
事务的四大特性为ACID,而innodb存储引擎完全符合ACID:
1、原子性(automicity):指整个数据库事务不可分割。要么都执行,要么都不执行。 2、一致性(consistency):指事务将数据库从一种状态转为另一种一致的状态,在事务开始前和结束后,数据库完整约束没有被破坏。 3、隔离性(isolation):(其他称呼:并发控制,可串行化,锁)指各个读写事务对象对其他事务操作相互分离,不可见。 4、持久性(durability):指事务完成后,其结果是永久的,即使机器宕机,也能够恢复。
二、提交方式
1.显式开启和提交。
使用begin或者start transaction来显式开启一个事务,显式开启的事务必须使用commit或者rollback显式提交或回滚。几种特殊的情况除外:行版本隔离级别下的更新冲突和死锁会自动回滚。
在存储过程中开启事务时必须使用start transaction,因为begin会被存储过程解析为begin...end结构块。
2.自动提交。(mysql默认的提交方式)
set autocommit = 0 禁用自动提交
不需要显式begin或者start transaction来显式开启事务,也不需要显式提交或回滚事务,每次执行DML和DDL语句都会在执行语句前自动开启一个事务,执行语句结束后自动提交或回滚事务
3.隐式提交事务
主要包括如下操作:
1.DDL语句(其中有truncate table)。 2.隐式修改mysql数据库架构的操作:create user,drop user,grant,rename user,revoke,set password。 3.管理语句:analyze table、cache index、check table、load index into cache、optimize table、repair table。
隐式提交的事务不受任何人为控制。truncate不能回滚
三、分类
主要分为如下五类:
1、扁平事务 2、带有保存点的扁平事务 3、链事务 4、嵌套事务 5、分布式事务
3.1、扁平事务
简单,所有操作都在同一个层次上,由begin work开始,由commit work或者rollback work结束,其操作都是原子的,要么都执行,要么都回滚,扁平事务三种不同的结果,分别是commit,rollback,等待超时。扁平事务的主要限制是不能提交或者回滚一部分,或者分几步提交。
3.2、带有保存点的扁平事务
除了支持扁平事务外,还能在事务的回滚中回滚到一个较早的状态。
保存点用来记录当前事务的状态,并告知系统。save work命令设置保存点,扁平事务默认有一个保存点1,也就是事务begin的地方,所以当我们设置保存点的时候是从2开始的。保存点在事务内是递增的。可以通过rollback work:2,回到保存点2。事务还处于活动状态,只有执行了rollback work,事务才结束
3.3、链事务
在提交一个事务时,释放不需要的数据对象,将必要处理的上下文隐式的传给下一个要开始的事务, 注意:提交事务操作和下一个事务开始操作合并为一个原子操作,这意味着下一个事务将看到上一个事务的结果。链事务不能随意回滚,只能回滚当前事务,即恢复到最近的一个保存点。链事务在执行commit操作立即释放持有锁,而带有保存点的扁平事务不影响迄今为止持有的锁。链事务的工作方式如下图所示:
3.4、嵌套事务
是一个层次结构框架,由一个顶层事务,控制着各个层次的事务。
嵌套事务是由若干事务组成的一棵树,子树既可以是嵌套事务,也可以是扁平事务
位于根节点的事务为顶层事务,其他为子事务,
子事务可以提交,也可以回滚,提交不会立马生效,要等其父事务提交。也就是要等顶层事务commit,才能保证每个子事务提交生效。
树中任意一个事务的回滚会引起它的所有子事务一同回滚,故子事务只保留了ACI特性,没有D
嵌套事务层次结构图如下图所示:
3.5、分布式事务
通常是一个分布式环境下的扁平事务。将多个服务器上的事务(节点)组合形成一个遵循事务特性(acid)的分布式事务。
innodb提供对XA事务的支持,并通过XA事务来支持分布式事务的实现,分布式事务允许多个独立的事务资源参与到一个全局的事务中。全局事务要求其中的事务要么全部提交,要么全部回滚。在使用分布式事务时,innodb存储引擎必须把事务隔离级别设置为SERIALIZABLE.
XA事务由一个多者多个资源管理器、一个事务管理器以及一个应用程序组成。
资源管理器:提供事务访问资源的方法,通常一个数据库就是一个资源管理器
事务管理器:协调参与全局事务中的各个事务,需要和参与全局事务的所有资源管理器进行通信
应用程序:定义事务的边界,指全局事务中的操作。
分布式事务采用两段式提交。在第一阶段参与全局事务的节点都开始准备,告诉事务管理器它们准备好了,在第二阶段,事务管理器通知资源管理器执行commit操作或者是rollback操作。
如上所说的分布式事务是外部事务,在mysql内部还有另外一种分布式事务,存在引擎和插件之间,又或存在引擎和引擎之间,称之为内部XA事务。
最常见的内部XA事务存在binlog和Innodb引擎之间,在主从复制中,在事务提交时,先写binlog日志,然后在写redo log日志。对上述的两个操作要求原子性,即binlog和redo log必须同时写入,如果binlog先写入了,而在写redo log的时候宕机了,那么slave会接收到master的binlog执行,导致主从不一致,如图下图所示:
如果执行完1,2后,在步骤3之前mysql发生了宕机,同样会导致主从不一致,为了解决这个问题,mysql在binlog和innodb引擎之间增加了内部XA事务。
当事务提交时,innodb引擎会做一个repeate操作,将事务的xid写入,接着写binlog,如果在写完binlog后宕机了,重启数据库会先检查准备的UXID事务是否提交,若没有,则存储引擎会继续提交一次。如下图所示:
四、事务控制语句
事务控制语句如下:
mysql默认自动提交事务,set autocommit = 0 禁用自动提交 显示开启事务:begin | start transaction 提交事务:commit | commit work 回滚事务:rollback | rollback work 设置保存点:savepoint identifier 删除保存点:release savepoint identifier 回滚到某个保存点:rollback to [savepoint] identifier 设置事务隔离级别:set transaction :READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE
commit 和 commit work的区别(由参数completion_type控制):
completion_type=0:二者完全等价(也是默认方式)
completion_type=1:commit work等同于commit and chain,表示提交当前事务,并马上开启一个相同隔离级别的事务
completion_type=2:commit work等同于commit and release,表示提交事务后,断开与服务器的连接。
rollback和rollback work与commit和commit work的工作一样,不再赘述
五、事务隔离级别
事务隔离级别如下:
1.READ UNCOMMITTED 2.READ COMMITTED 3.REPEATABLE READ 4.SERIALIZABLE
5.1、查看和设置隔离级别
MySQL中默认的隔离级别是repeatable read,innodb存储引擎通过next-key lock解决幻读问题
设置隔离级别:
隔离级别是基于会话设置的,当然也可以基于全局进行设置,设置为全局时,不会影响当前会话的级别。设置的方法是:
set [global | session] transaction isolation level type
type:
read uncommitted | read committed | repeatable read | serializable
或者直接修改变量值:
set @@global.tx_isolation = ‘read-uncommitted‘ | ‘read-committed‘ | ‘repeatable-read‘ | ‘serializable‘
set @@session.tx_isolation = ‘read-uncommitted‘ | ‘read-committed‘ | ‘repeatable-read‘ | ‘serializable‘
查看当前会话的隔离级别:
mysql> select @@tx_isolation;
mysql> select @@global.tx_isolation;
5.2、read uncommitted
该级别称为未提交读,即允许读取未提交的数据(脏读)。
在该隔离级别下,读数据的时候不会申请读锁,所以也不会出现查询被阻塞的情况
该隔离级别问题太多,会导致脏读、丢失的更新、幻影读、读不一致的问题。但由于不申请读锁,从理论上来说,它的并发性是最佳的。所以在某些特殊情况下还是会考虑使用该级别。
5.3、read committed
允许不可重复读和允许幻读,不可重复读指在一个事务中多次读取同一份数据,在这个事务没有结束过程中,其他事务对这份数据进行了修改,这样就导致这个事务读取到的数据和之前一次的数据是不一样的,这就是不可重复读。
幻读和不可重复读的区别:
不可重复读:A事务在执行过程中,B事务对数据进行了修改或删除,导致A两次读取的数据不一致;重点在于delete和update操作,锁行可以解决问题
幻读:A事务在执行过程中,B事务新增了符合A事务要查询的数据,导致A两次读取的数据不一致;重点在于insert操作,锁表或者锁范围可以解决
5.4、repeatable read
MySQL中repeatable read级别总是会在事务开启的时候读取最新提交的行版本,并将该行版本一直持有到事务结束
innodb存储引擎使用next-key lock算法,它会进行范围锁定。这就避免了幻影读的问题
5.5、serializable
MySQL中的serializable其实类似于repeatable read,只不过所有的select语句会自动在后面加上lock in share mode。也就是说会对所有的读进行加锁,而不是读取行版本的快照数据,也就不再支持"一致性非锁定读"。这样就实现了串行化的事务隔离:每一个事务必须等待前一个事务(哪怕是只有查询的事务)结束后才能进行哪怕只是查询的操作
其他mysql文章请看:MYSQL学习系列
参考:
《msyql技术内幕:innodb存储引擎》
https://www.cnblogs.com/f-ck-need-u/p/8997814.html#2-1-
以上是关于mysql事务的主要内容,如果未能解决你的问题,请参考以下文章