Fix “更新丢失” to “丢失更新” in ch7.md

第一处

原文：

> However, read committed does not prevent the race condition between two
> counter increments in Figure 7-1. In this case, the second write happens after the
> first transaction has committed, so it’s not a dirty write. It’s still incorrect, but for
> a different reason—in **“Preventing Lost Updates”** on page 242 we will discuss how
> to make such counter increments safe.

翻译：

> 但是，读已提交并不能防止 [图 7-1](https://github.com/Vonng/ddia/blob/master/img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 **“[防止更新丢失](https://github.com/Vonng/ddia/blob/master/ch7.md#%E9%98%B2%E6%AD%A2%E4%B8%A2%E5%A4%B1%E6%9B%B4%E6%96%B0)”** 中将讨论如何使这种计数器增量安全。

--------------

第二处

原文：

> **Lost updates**
> Two clients concurrently perform a read-modify-write cycle. One overwrites the
> other’s write without incorporating its changes, so data is lost. Some implemen‐
> tations of snapshot isolation prevent this anomaly automatically, while others
> require a manual lock (SELECT FOR UPDATE).

翻译：

> **更新丢失**
> 两个客户端同时执行 读取 - 修改 - 写入序列。其中一个写操作，在没有合并另一个写入变更情况下，直接覆盖了另一个写操作的结果。所以导致数据丢失。快照隔离的一些实现可以自动防止这种异常，而另一些实现则需要手动锁定（SELECT FOR UPDATE）。

ch7.md

@@ -263,7 +263,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
 通过防止脏写，这个隔离级别避免了一些并发问题：
 
 - 如果事务更新多个对象，脏写会导致不好的结果。例如，考虑 [图 7-5](img/fig7-5.png)，以一个二手车销售网站为例，Alice 和 Bob 两个人同时试图购买同一辆车。购买汽车需要两次数据库写入：网站上的商品列表需要更新，以反映买家的购买，销售发票需要发送给买家。在 [图 7-5](img/fig7-5.png) 的情况下，销售是属于 Bob 的（因为他成功更新了商品列表），但发票却寄送给了 Alice（因为她成功更新了发票表）。读已提交会防止这样的事故。
-- 但是，读已提交并不能防止 [图 7-1](img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 “[防止更新丢失](#防止丢失更新)” 中将讨论如何使这种计数器增量安全。
+- 但是，读已提交并不能防止 [图 7-1](img/fig7-1.png) 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 “[防止丢失更新](#防止丢失更新)” 中将讨论如何使这种计数器增量安全。
 
 ![](img/fig7-5.png)
 
@@ -845,7 +845,7 @@ WHERE room_id = 123 AND
 
   在同一个事务中，客户端在不同的时间点会看见数据库的不同状态。**快照隔离** 经常用于解决这个问题，它允许事务从一个特定时间点的一致性快照中读取数据。快照隔离通常使用 **多版本并发控制（MVCC）** 来实现。
 
-* 更新丢失
+* 丢失更新
 
   两个客户端同时执行 **读取 - 修改 - 写入序列**。其中一个写操作，在没有合并另一个写入变更情况下，直接覆盖了另一个写操作的结果。所以导致数据丢失。快照隔离的一些实现可以自动防止这种异常，而另一些实现则需要手动锁定（`SELECT FOR UPDATE`）。