事务隔离：为什么你改了我还看不见？

---

隔离性与隔离级别

• 事务的特性： ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）

  • 原子性（Atomicity）：一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作。
  • 一致性（Consistency）：一个事务在执行之前和执行之后，数据库都必须处于一致性状态，比如说不能破坏字段的唯一性约束等。
  • 隔离性（Isolation）：事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。
  • 持久性（Durability）：一旦事务提交，那么它对数据库中对应数据的状态的变更会永久保存到数据库中。

• 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了“隔离级别”的概念。

  • 脏读（dirty read）：当 A 事务正在对数据进行修改，而这种修改还没有提交到数据库中，这时，B 事务访问并使用了 A 未提交的数据，如果 A 事务回滚了，那 B 事务读取到的就是脏数据了。
  • 不可重复读（non-repeatable read）：指在一个事务内，多次读同一数据的结果不一致。A 事务访问了 d 数据为 500，还未提交事务，事务 B 修改了 d 数据为 1000，并且提交了，A 事务再次读取 d 数据为 1000，导致了同一事务两次读取不一致。
  • 幻读（phantom read）：请参考 幻读是什么，幻读有什么问题？

• SQL 标准的事务隔离级别包括以下

  • 读未提交（read uncommitted），一个事务还没提交时，它做的变更就能被别的事务看到
  • 读提交（read committed），一个事务提交之后，它做的变更才会被其他事务看到
  • 可重复读（repeatable read），一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的
  • 串行化（serializable ），顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行

• 在事务隔离的实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准

  • 在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图
  • 在读提交隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的
  • 在读未提交隔离级别下，直接返回记录上的最新值，没有视图概念
  • 在串行化隔离级别下，直接用加锁的方式来避免并行访问

事务隔离级别	symbol	更新丢失	脏读	不可重复读	幻读
未提交读	READ-UNCOMMITTED	避免	发生	发生	发生
已提交读	READ-COMMITTED	避免	避免	发生	发生
可重复读	REPEATABLE-READ	避免	避免	避免	发生
串行化	SERIALIZABLE	避免	避免	避免	避免

• 对 select 操作手动加行（X）锁：SELECT ... FOR UPDATE

---

事务隔离的实现

• 事务隔离的实现：每条记录在更新的时候都会同时记录一条回滚操作，同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。
• 回滚日志（undo log）什么时候删除？系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。什么时候不需要了？当系统里没有比这个回滚日志更早的 read-view 的时候。
• 尽量不要使用长事务。长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。

---

事务的启动方式

• 方法一：显式启动事务语句，begin 或者 start transaction，提交 commit，回滚 rollback
• 方法二：set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个 select 语句，事务就启动，并不会自动提交，直到主动执行 commit 或 rollback 或断开连接。
• 建议使用方法一，如果考虑多一次交互问题，可以使用 commit work and chain 语法。在 autocommit=1 的情况下用 begin 显式启动事务，如果执行 commit 则提交事务。如果执行 commit work and chain 则提交事务并自动启动下一个事务。
• begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用 start transaction with consistent snapshot 这个命令。

---

笔记来源于《极客时间：MySQL实战45讲：事务隔离：为什么你改了我还看不见？》