From e14180fe7aabd1c3bef1bafc218ff6f5d72184ed Mon Sep 17 00:00:00 2001
From: Ozarklake <67998142+Ozarklake@users.noreply.github.com>
Date: Wed, 8 Jul 2020 14:55:09 +0800
Subject: [PATCH 1/2] typo

---
 ch7.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ch7.md b/ch7.md
index 8bd88637..f0f97e51 100644
--- a/ch7.md
+++ b/ch7.md
@@ -290,7 +290,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
 
 ### 快照隔离和可重复读
 
-如果只从表面上看读已提交隔离级别你就认为它完成了事务所需的一切，那是可以原谅的。它允许**中止**（原子性的要求）；它防止读取不完整的事务结果，并且防止并发写入造成的混合。事实上这些功能非常有用，比起没有事务的系统来，可以提供更多的保证。
+如果只从表面上看读已提交隔离级别你就认为它完成了事务所需的一切，那是可以原谅的。它允许**中止**（原子性的要求）；它防止读取不完整的事务结果，并且防止并发写入造成的混乱。事实上这些功能非常有用，比起没有事务的系统来，可以提供更多的保证。
 
 但是在使用此隔离级别时，仍然有很多地方可能会产生并发错误。例如[图7-6](img/fig7-6.png)说明了读已提交时可能发生的问题。
 

From 15fcae91ccad24e0878a1e96c9d141e2ff467763 Mon Sep 17 00:00:00 2001
From: Ozarklake <67998142+Ozarklake@users.noreply.github.com>
Date: Thu, 20 Aug 2020 10:18:32 +0800
Subject: [PATCH 2/2] typo

---
 ch3.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ch3.md b/ch3.md
index 8cbf6fed..b2734912 100644
--- a/ch3.md
+++ b/ch3.md
@@ -193,7 +193,7 @@ $ cat database
 
 #### 用SSTables制作LSM树
 
-这里描述的算法本质上是LevelDB 【6】和RocksDB 【7】中使用的关键值存储引擎库，被设计嵌入到其他应用程序中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了类似的存储引擎【8】，这两种引擎都受到了Google的Bigtable文档【9】（引入了SSTable和memtable）的启发。
+这里描述的算法本质上是LevelDB 【6】和RocksDB 【7】中使用的键值存储引擎库，被设计嵌入到其他应用程序中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了类似的存储引擎【8】，这两种引擎都受到了Google的Bigtable文档【9】（引入了SSTable和memtable）的启发。
 
 最初这种索引结构是由Patrick O'Neil等人描述的。在日志结构合并树（或LSM树）【10】的基础上，建立在以前的工作上日志结构的文件系统【11】。基于这种合并和压缩排序文件原理的存储引擎通常被称为LSM存储引擎。