幻读

数据库的事务应该保证隔离性，这就是说，两个用户（连接）在操作数据库的时候，它们之间的操作应该互相不受影响的。比如用户 A 在修改了 foo 这个变量，但是还没有提交，那么 B 不应该看到这个修改。

但是隔离性的时间不是一件简单的时间，隔离性保证的越高，要么实现的技术手段越复杂，要么性能很低。因为很显然，避免多个事务之间互相影响，就必然要通过加锁来同步操作。如果想要更高的性能，就必须要加更加细粒度的锁，或者使用无锁（更加复杂）的技术来实现。

隔离性一般有这几个问题：

1. 读到了未提交的数据。这个比较好理解，也比较好解决。一般加锁就行。
2. 在同一个事务中，两次读到的数据不一样。比如用户 A 开始了一个事务，查询了 foo，这时候用户 B 修改了 foo 并且提交了，然后 A 在事务中又查询了 foo，发现和上一次查询不一样。这也违反了“隔离性”，但是读到的数据却的确是已经提交的数据。这就是“不可重复读”问题。现在用 MVCC 的方式解决，大体意思就是一个事务开始的时候记一个版本（时间戳）v1，其他人所有的操作都会带上新的版本（时间戳），那么在这个事务中，所看到的所有的数据都是先于 v1 的，所有在 v1 之后提交的数据都看不到。MVCC 有一些 tricky 的地方，比如要删除数据的时候，不能直接删除，因为删除了的话，对于所有的事务（即使是在删除操作 commit 之前开始的事务）来说都看不到了。为了解决这个问题，需要在要删除的对象上标记一个新的版本，记为删除。这样之前的事务看到这个数据的时候，发现删除操作是在自己的事务版本之后的，就仍然可以读到这个对象。这样，就可以解决了同一个事务中读到的数据不一样的问题。（但这样其实会带来新的问题，比如数据标记新的版本了，那么索引要不要标记呢？索引怎么做隔离？比如 PostgresSQL 的 COUNT 其实不是一个 O(1) 的操作，而是要遍历每一行数据，检查数据对当前的事务是否是可见的。
3. 幻读。上面说这么多，主要是给这个问题做铺垫，我觉得这个问题最有意思了。本文下面会主要讲讲幻读。

假设这么一种情况：一家医院规定必须至少有 1 名医生在值班，某天值班医生 A 和 B 感到不舒服想请假，按照系统的要求，不能让 A 和 B 同事请假成功的。如果我们使用的数据库没有解决了幻读的问题，那么即使解决了“重复读”问题，也是不正确的。考虑下面这种情况：

这样两人都会同时请假成功。

这个问题并不是“不可重复读”问题，因为两个事务看到的正是事务开头的数据。这个竞争条件产生的根本原因是，这两个事务互相依赖了别的对象，但是别的对象又被更改了。

在这种情况中，我们可以锁住所有的对象，强制他们只能一个接一个的执行。

再举一个幻读的例子：抢占会议室。

抢占程序是这样的，先检查会议室 R 在 某一天 12:00 有没有被抢占，如果没有的话，就可以抢占。那么假如两个事务同时发起的话，就同时看到这个会议室并没有被抢占，就会错误地被抢占两次。被抢占两次的 SQL 过程如下：

这个问题我们也可以通过加锁来解决：将不存在的锁转换成已经存在的。比如，只允许抢占 7 天内的会议室，并且以小时为单位进行抢占。然后就可以将 7 天内的每一个小时作为一个锁，要抢占这个会议室就必须先获得锁。

另外有一些问题不容易实例化不存在的锁。比如注册系统，不允许同一个用户名字被注册两次。但是这种情况可以用数据库的 unique 约束来解决。

不太好解决的问题，防止双重开支。支付系统要保证用户支付的钱不能大于自己的余额，不然公司要倒闭了。那么付款的事务中，我们先检查一下余额是否足够，然后在发起支付，这样可以吗？如果用户同时用电脑付款，也用手机付款，会不会在同一个事务中提交两次呢？

这些问题都有一种共同的模式：

1. 执行一个 select 查询；
2. 根据 1 的查询结果，判断当前的操作是否能够继续；
3. 如果能，就继续，但是这个操作会改变 1 的结果；

因为事务进入的时候 2 都是检查通过的，但是都执行了 3，会影响彼此的 1 的结果，导致出现竞争条件。这就是幻读。

除了“强行加锁”，即上文中提到的方法以外。最靠谱的是使用串行化的隔离级别，即对于程序员来说，数据库好像在串行地一个一个执行事务，这样永远不会有竞争条件。但是因为性能问题，串行化很少使用。

注：本文内容大多数都阅读 DDIA 第七章的笔记。