❤️个人主页：水滴V2 🚀支持水滴：点赞👍、收藏⭐、留言💬

大家好，我是水滴~~

事务（Transaction）是一个独立的工作单元，它由一组具有原子性的 SQL 语句构成，通常该组 SQL 语句对应着一个完整的业务。在事务内的语句，要么全部执行成功，要么全部执行失败。

我们使用一个典型的“转账”例子来解释事务。下表为用户表user，每个用户都有自己的余额balance（该表的存储引擎为 InnoDB)。

现在要从“刘一”账号中转账20元给“陈二”，那么至少需要两个步骤：

上述两个步骤作，在不使用事务的情况下，如果第二步没有执行成功，那么“刘一”余额已经减去了20元，而“陈二”的余额没有变化，会造成数据不一致。所以这两个步骤必须放在一个事务中，它们就是一个独立的工作单元，任何一个步骤失败，则必须回滚所有步骤。

事务中，有三种操作：

那么这个转账事务的 SQL 语句如下：

❤️ 在事务提交之前，存储引擎在修改表数据时，并不是直接修改磁盘中的数据库文件，而是先在内存中修改。事务提交后，才会将内存中修改的数据刷回磁盘中。这块内容在后面的“事务日志”章节再详聊。

一个运行良好的事务处理系统，必须要具备 ACID 标准特性。

一个事务必须是一个不可分割的最小工作单元，整个事务中所有操作要么全部成功提交，要么全部失败回滚。

一致性描述了数据库中数据的状态，数据总是从一个一致的状态转换为另一个一致的状态。

在上例中，一致性确保了：转账成功，“刘一”的钱减少了20元，“陈二”的钱增加了20元；转账失败，“刘一”和“陈二”的钱都没有变化，因为事务中所有操作全部回滚，并没有保存到数据库中。

在多个事务并发执行时，一个事务所做的修改在提交以前，对其他事务“通常来说”是不可见的，它们是相互隔离的。

之所以是“通常来说”是不可见的，是因为事务具有隔离级别（Isolation Level）。隔离级别不同，可见性也不同，后面章节会有介绍。

一旦事务提交后，其所做的修改就会永久保存到数据库中。

❤️ 事务的 ACID 特性可以确保转账时不会弄丢你的钱，为了确保事务处理过程中是安全的，也需要数据库系统做更多的额外工作。一个实现了 ACID 的存储引擎，通常会需要更强的 CPU 处理能力、更大的内存和更多的磁盘空间。这也正是 MySQL 存储引擎架构的强大之处，用户可以根据业务是否需要事务处理，来选择合适的存储引擎 。对于一些不需要事务操作的应用，选择一个非事务型存储引擎，可以获得更高的性能。

在 SQL 标准中定义了四种隔离级别，每一种隔离级别都规定了一个事务中所做的修改，哪些在事务内和事务间是可见，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。

在未提交读级别中，事务中的修改，即使没有提交，对其他事务也是可见的。

事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，在实际应用中一般很少使用。

一个事务在提交之前所做的任何修改，对其他事务是不可见的，只有提交后才能被其他事务“看到”。

这个级别也被叫做不可重复读（Nonrepeatable Read），因为两次执行同样的查询，结果可能不一样。

该级别是大多数数据库系统的默认隔离级别（MySQL 不是）。

该级别保证了在同一个事务中，多次读取同样记录的结果是一致的。

理论上，可重复读还是无法解决另一个幻读（Phantom Read）的问题。所谓幻读，指的是当 A 事务在读取某个范围内的记录时，B 事务往该范围内插入了新的记录，那么 A 事务再次读取该范围时，就会产生幻行（Phantom Row）。而InnoDB 和 XtraDB 存储引擎通过多版本并发控制（MVCC）解决了幻读的问题。

该级别是 MySQL 的默认隔离级别。

可串行化是最高的隔离级别，它通过强制事务串行执行，避免了前面说的幻读问题。

该级别通过在读取的每一行记录上加锁，实现的串行执行，所以可能会导致大量的超时和锁竞争问题，在实际应用中也很少使用。

ANSI SQL 隔离级别：

死锁是指两个或多个事务，在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。

例如，下面两个事务同时处理user表：

事务 A：

事务 B：

如果两个事务都执行了第一条update语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条update语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又待有对方需要的锁，就会陷入一种死循环。

下面使用刚才的事务 A 和事务 B 来演示下死锁：

数据库系统是有死锁检测和处理机制的，我们看到上例中的 InnoDB 存储引擎，能够检测到死锁的循环依赖，并立即返回一个错误。

❤️ InnoDB处理死锁的方法是，将持有最少行级排他锁的事务进行回滚，其他事务就可以获到锁了。

在修改表的数据时，实际修改的是其内存的拷贝，存储引擎会将修改的行为记录到磁盘上的事务日志中。事务日志持久以后，内存中被修改的数据会被存储引擎慢慢地刷回磁盘数据库文件中。也就是说，修改数据需要写两次磁盘。

如果数据的修改已经持久化到事务日志中，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具体的恢复方式视存储引擎而定。

MySQL提供了两种事务型存储引擎：InnoDB 和 NDB Cluster。另外还有一些第三方存储引擎也支持事务，比如：XtraDB 和 PBXT。

MySQL 默认使用的是自动提交（Autocommit）模式。也就是说，MySQL 中的每个 SQL 操作都被当作一个事务执行提交操作。当然你也可以禁用自动提交模式，改为手动提交，但这种方式不推荐。

对于非事务型存储引擎，如 MyISAM，不会受事务影响，这类表没有commit或rollback的概念，你可以理解它是一直处于自动提交模式。

事务是由存储引擎来实现，不能在一个事务中混合使用事务型和非事务型的表（例如 InnoDB 和 MyISAM 表）。

如果混合使用，而事务需要回滚时，非事务型的表上的修改就无法撤销了，违反了事务的一致性。

InnoDB 采用的是两阶段锁定协议（Two-phase Locking Protocol）。在事务执行过程中，如果执行到 DML 语句时，会自动将范围内的记录锁定。锁只有在执行commit或者rollback的时候才会释放，并且是事务内所有锁在同一时刻被翻译。这种方式的锁定就是隐式锁定。

DML（Data Manipulation Language，数据操作语言）主要有三种方式：插入（INSERT）、修改（UPDATE）和删除（DELETE）。

显式锁定通过一些特定的语句来实现，在上一篇《高性能 MySQL（二）：并发控制（锁）》中已经介绍过：