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

[Ynjxsjmh]

第一处

原文：

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 中两个计数器增量之间的竞争状态。在这种情况下，第二次写入发生在第一个事务提交后，所以它不是一个脏写。这仍然是不正确的，但是出于不同的原因，在 “防止更新丢失” 中将讨论如何使这种计数器增量安全。

---

第二处

原文：

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）。

[yingang]

Thanks for your contribution!