事务

需要保证 原子性 、 隔离性 、 一致性 和 持久性 的一个或多个数据库操作称之为一个 事务

原子性（Atomicity）

一致性（Consistency）

​ 保证一致性的努力：

• 数据库本身能为我们保证一部分一致性需求。
• 更多的一致性需求需要靠写业务代码的程序员自己保证。

隔离性（Isolation）

持久性（Durability） 数据从内存刷到磁盘

持久性是通过 redo log （重做日志）来保证的； 原子性是通过 undo log（回滚日志） 来保证的； 隔离性是通过 MVCC（多版本并发控制） 或锁机制来保证的； 一致性则是通过持久性+原子性+隔离性来保证；

原子性和一致性一样吗？如何看待？

原子性，要么一起执行，要么一起回滚，更看重过程。一致性，数据前后状态是一致的，更看重数据库的状态，就像能量守恒定律

事务的状态

• 活动的（active）

事务对应的数据库操作正在执行过程中时，我们就说该事务处在 活动的 状态。

• 部分提交的（partially committed）

当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并没有刷新到磁盘时，我们就说该事务处在 部分提交的 状态。

• 失败的（failed）

当事务处在 活动的 或者 部分提交的 状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续

执行，或者人为的停止当前事务的执行，我们就说该事务处在 失败的 状态。

• 中止的（aborted）

如果事务执行了半截而变为 失败的 状态，比如我们前边唠叨的狗哥向猫爷转账的事务，当狗哥账户的钱被扣除，但是猫爷账户的钱

没有增加时遇到了错误，从而当前事务处在了 失败的 状态，那么就需要把已经修改的狗哥账户余额调整为未转账之前的金额，换句

话说，就是要撤销失败事务对当前数据库造成的影响。书面一点的话，我们把这个撤销的过程称之为 回滚 。当 回滚 操作执行完毕

时，也就是数据库恢复到了执行事务之前的状态，我们就说该事务处在了 中止的 状态。

• 提交的（committed）

当一个处在 部分提交的 状态的事务将修改过的数据都同步到磁盘上之后，我们就可以说该事务处在了 提交的 状态。

只有当事务处于提交的或者中止的状态时，一个事务的生命周期才算是结束了

事务的语法

开启事务

begin;
或者
start transaction;

提交事务

coomit;

手动终止事务

rollback;
-- ROLLBACK 语句是我们程序员手动的去回滚事务时才去使用的，如果事务在执行过程中遇到了某些错误而无法继续执行的话，事务自身会自动的回滚。

支持事务的存储引擎

innoDB和NDB存储引擎。

自动提交

MySQL 中有一个系统变量 autocommit；

查询

SHOW VARIABLES LIKE 'autocommit';

开启

SET autocommit = ON;

关闭

SET autocommit = OFF;

隐式提交

就算沒有显性执行commit,有一些操作也会悄悄地把提交给执行了。比如，执行DDL语言，重复执行开启事务的语句等等。

保存点

开启事务后，标记了保存点，如果发生回滚操作，不会一下回到事务开始之前的样子，而是可以指定回滚到某个保存点。

定义保存点的语法如下：

SAVEPOINT 保存点名称;

当我们想回滚到某个保存点时，可以使用下边这个语句（下边语句中的单词 WORK 和 SAVEPOINT 是可有可无的）：

ROLLBACK [WORK] TO [SAVEPOINT] 保存点名称;

不过如果 ROLLBACK 语句后边不跟随保存点名称的话，会直接回滚到事务执行之前的状态。

刪除保存点

RELEASE SAVEPOINT 保存点名称;