MySQL 事务深度解析：ACID 特性与隔离级别实战

一、事务介绍

事务是一组 DML 相关的语句集合，这些指令要么全部成功，要么全部失败，满足如下性质：

• 原子性（Atomicity）：操作不可分割，要么全成要么全败。
• 一致性（Consistency）：事务前后数据库完整性不被破坏。
• 隔离性（Isolation）：并发事务互不干扰，避免脏读、幻读等问题。
• 持久性（Durability）：事务提交后，数据修改永久有效。

二、为什么要有事务

事务是为了服务应用层而存在。数据库是存储数据的地方，应用层对数据进行的操作必须保障数据的一致性。这些关注点（如修改是否成功、数据是否会丢失）应交由 MySQL 自行实现，因此它是一个服务机制。

三、事务的版本支持

在 MySQL 中，只有使用了 InnoDB 数据库引擎的数据库或表才支持事务，MyISAM 不支持。

mysql> show engines;          -- 表格显示
mysql> show engines \G;       -- 行显示

四、事务提交的两种方式

事务的提交方式常见的有两种：自动提交和手动提交。

查看事务提交方式：

show variables like 'autocommit';

用 SET 来改变 MySQL 的自动提交模式：

SET AUTOCOMMIT=0;   # 禁止自动提交
SET AUTOCOMMIT=1;   # 开启自动提交

五、事务的几种操作

（1）开始一个事务

begin;

（2）创建一个保存点

savepoint 自命名;

（3）回滚到指定保存点

rollback to 保存点名字;

（4）正常结束一个事务

注意：正常结束一个事务后，不支持回滚。

commit;

（5）异常结束一个事务

注意：异常结束自动回滚，由于原子性，自动回到事务未提交时的数据状态。

六、事务隔离级别

（1）读未提交

在该隔离级别，所有的事务都可以看到其他事务没有执行的执行结果。实际生产中不可能使用这种隔离级别，因为它没有任何隔离性，会有脏读、幻读、不可重复读等并发问题。

理解：假设多个客户端并发访问操作同一个数据，单个客户端的任何操作不管提交与否，其他人看得到。

总结：不管对方提交与否，都看得到数据的修改。

（2）读提交

该隔离级别是大多数数据库默认的隔离级别（不是 MySQL 默认）。它满足隔离的简单定义：一个事务只能看到其他已经提交的事务所做的改变。这种隔离级别会引起不可重复读，即一个事务执行时，如果多次 SELECT，可能得到不同的结果。

理解：假设 A 在操作一个事务，B 也在操作一个事务。A 和 B 都在修改表 1，A 在执行 COMMIT 之前，B 是看不到 A 做出的修改的。一旦 A 做出了提交，B 就可以看到 A 的修改。

总结：只要对方提交了，哪怕是多个事务，数据修改就会被其他人看到。

（3）可重复读

这是 MySQL 默认的隔离级别，它确保同一个事务在执行中，多次读取操作数据时，会看到同样的数据行。但是会有幻读问题！

理解：假设 A 在操作一个事务，B 也在操作一个事务。A 和 B 如果操作同一个表，此时 A 完成了提交，B 是看不到修改的，B 看到的是 B 进入该事务开始时的数据。如果 A 退出事务了，那么 B 的数据就会更新到最新的。

总结：只有单方提交且退出事务，对方才看得到更改。

什么是幻读？假设 A 修改了张三的年龄，然后提交退出事务，B 此时可能在筛选年龄时出现两个张三，因为 A 提交且退出事务了，B 就会更新数据。

（4）串行化

这是事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决了幻读的问题。它在每个读的数据行上面加上共享锁！

总结：一把锁，你访问数据是没有问题的，当你修改数据时，只有在你前一个事务修改完了你才可以执行修改的操作，即串行化，唯一就是效率低。

七、事务相关结论

1. 持久化保障：只要开始一个事务，输入 BEGIN 或者 START TRANSACTION，事务便必须要通过 COMMIT 提交，才会持久化，与是否设置自动提交无关。
2. 事务可以手动回滚，同时，当操作异常，MySQL 会自动回滚。

以上可以看出事务的原子性和持久性：要么成功要么不成功，数据一经提交，就是持久化。而原子性保障了数据的一致性。

八、修改事务隔离级别

• 读未提交：SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
• 读提交：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
• 可重复读（默认）：SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
• 串行化：SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

九、客户端会话与事务关系

客户端会话并非是一个事务，一个客户端中可以允许多个事务，事务之间相互独立。

十、进阶：数据并发的场景

数据并发场景有以下三种：

• 读 - 读：不存在任何问题，也不需要并发控制。
• 读 - 写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读、幻读、不可重复读。
• 写 - 写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失。

多个用户访问同一块数据不存在安全问题，因为只访问不修改。

读 - 写

用来解决读 - 写的方案：多版本并发控制（MVCC）（无锁并发控制）。

解决问题：读写互不阻塞。

如何解决？

MVCC 依靠三个工具：

1. 数据的额外三个标签：最近修改的事务 ID、回滚指针、隐式主键。
2. 快照仓库（针对写操作）：当修改数据时会保存一份原始数据在 undo 日志里面，回滚指针指向该原始数据。
3. 读视图（针对读操作）：形成读视图，给当前事务划分可见范围，看不到未提交的或者在你后面提交的数据版本。

运行过程：当 A 去修改数据时，会加行锁（保证修改的原子性），先将原始数据放在 undo 仓库。如果有读端访问，访问的是 undo 仓库里面的，看不到 A 的修改，因为有视图范围，读写可以同时进行。视图通过划分范围可以自行屏蔽脏读——四种隔离性无非是对这三个工具'度'的把控。