事务就是一组DML语句组成,这些语句在逻辑上存在相关性,这一组DML语句要么全部成功,要么全部失败,是一个整体。MySQL提供一种机制,保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。
一个完整的事务,绝对不是简单的 sql 集合,还需要满足如下四个属性:
上面四个属性,可以简称为 ACID 。
事务被 MySQL 编写者设计出来,本质是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型, 不需要我们去考虑各种各样的潜在错误和并发问题。
因此事务本质上是为了应用层服务的,而不是伴随着数据库系统天生就有的。
事务的提交方式常见的有两种:
查看事务提交方式
show variables like 'autocommit';
改变 MySQL 的自动提交模式:
SET AUTOCOMMIT=0; // 禁止自动提交
SET AUTOCOMMIT=1; // 开启自动提交
测试用事务处理表操作:
start transaction;--开启一个事务,也可以使用 begin ,推荐使用 begin
savepoint save1;--创建一个保存点 save1
xxxxxxx;--进行一系列表操作
savepoint save2;--创建一个保存点 save2
xxxxxxx;--进行一系列表操作
至此,我们创建了两个保存点,并且在保存点之后,进行了若干表操作。
rollback to save2;--回滚到保存点2
rollback;--回滚到最开始
当回滚到某个保存点时,该保存点之后的表操作将消失,表的内容回归到该保存点被建立时的状态;如果直接回滚到最开始,那么所有的表操作都将消失,表也将回归到事务开始时的样子。
回滚之后仍可继续进行事务操作。
commit;--提交事务
在事务运行期间,可以随时进行回滚操作,如果事务被提交,就不能再进行回滚操作,同时事务也将被关闭。
此外,如果在事务开启时,此时MySQL客户端异常退出,如果没有进行commit提交,将会发生自动回滚,事务开启后的所有操作荡然无存;如果提前进行的commit提交,由于数据已经插入数据库,所以数据将会被保留。
在之前我们对数据库做各种操作时,都没有使用过 begin 或者 start transaction 开启事务,但事实上我们所用的每一条 SQL 语言都默认被封装成事务,它们会根据 autocommit 的设定,如果是自动提交,则执行后数据库就会立马发生变化,如果设置的是手动提交,则必须通过 commit 提交,数据库才会发生变化。
但是如果是使用 begin或者start transaction 启动的事务,事务便必须要通过 commit 提交,才会持久化,与是否设置set autocommit无关。
从上面的例子,我们能看到事务本身的原子性(回滚),持久性(commit)。
MySQL服务可能会同时被多个客户端进程(线程)访问,访问的方式以事务方式进行。
一个事务可能由多条SQL构成,也就意味着,任何一个事务,都有执行前,执行中,执行后的阶 段。所有事务都要有个执行过程,那么在多个事务各自执行多个SQL的时候,就还是有可能会出现互相影响的情况。比如:多个事务同时访问同一张表,甚至同一行数据。
数据库中,为了保证事务执行过程中尽量不受干扰,就有了一个重要特征:隔离性。
数据库中,允许事务受不同程度的干扰,就有了一种重要特征:隔离级别。
隔离级别:
事务并发可能引发的问题:
同一个事务内,同样的读取,在不同的时间段 (依旧还在事务操作中!),读取到了不同的值(其他事务对读取的数据改动并 commit 了),这种现象叫做不可重复读。
数据库在可重复读情况的时候,无法屏蔽其他事务insert的数据,会造成虽然大部分内容是可重复读的,但是insert的数据在可重复读情况被读取出来,导致多次查找时,会多查找出来新的记录,就如同产生了幻觉。这种现象,叫做幻读。
查看隔离性:
SELECT @@global.tx_isolation; --查看全局隔离级别
SELECT @@session.tx_isolation; --查看会话(当前)全局隔离级别
SELECT @@tx_isolation; --查看会话(当前)全局隔离级别
设置隔离性:
-- 设置当前会话 or 全局隔离级别语法
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READCOMMITTED | REPEATABLE READ | SERIALIZABLE}
事务执行的结果,必须使数据库从一个一致性状态,变到另一个一致性状态。当数据库只包含事务 成功提交的结果时,数据库处于一致性状态。如果系统运行发生中断,某个事务尚未完成而被迫中 断,而该未完成的事务对数据库所做的修改已被写入数据库,此时数据库就处于一种不正确(不一 致)的状态。因此一致性是通过原子性来保证的。
一致性和用户的业务逻辑强相关,一般MySQL提供技术支持,但是一致性还是要用户业务逻辑做支撑,也就是一致性是由用户决定的。
在技术上,事务的原子性、隔离性和持久性保证了事务的一致性。