From be51c8c1c7dc53faee698f8ab8926fab8c563e0f Mon Sep 17 00:00:00 2001
From: songzhibin97 <49082129+songzhibin97@users.noreply.github.com>
Date: Fri, 6 May 2022 10:01:12 +0800
Subject: [PATCH] Update ch7.md

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

diff --git a/ch7.md b/ch7.md
index 34007fd..239eac0 100644
--- a/ch7.md
+++ b/ch7.md
@@ -275,7 +275,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
 
 最常见的情况是，数据库通过使用 **行锁（row-level lock）** 来防止脏写：当事务想要修改特定对象（行或文档）时，它必须首先获得该对象的锁。然后必须持有该锁直到事务被提交或中止。一次只有一个事务可持有任何给定对象的锁；如果另一个事务要写入同一个对象，则必须等到第一个事务提交或中止后，才能获取该锁并继续。这种锁定是读已提交模式（或更强的隔离级别）的数据库自动完成的。
 
-如何防止脏读？一种选择是使用相同的锁，并要求任何想要读取对象的事务来简单地获取该锁，然后在读取之后立即再次释放该锁。这能确保在读取进行时，这将确保在对象具有脏的、未提交的值时不会发生读取(因为在此期间，锁将由进行写入的事务持有)。
+如何防止脏读？一种选择是使用相同的锁，并要求任何想要读取对象的事务来简单地获取该锁，然后在读取之后立即再次释放该锁。这能确保在读取进行时，确保在对象具有脏的、未提交的值时不会发生读取(因为在此期间，锁将由进行写入的事务持有)。
 
 但是要求读锁的办法在实践中效果并不好。因为一个长时间运行的写入事务会迫使许多只读事务等到这个慢写入事务完成。这会损失只读事务的响应时间，并且不利于可操作性：因为等待锁，应用某个部分的迟缓可能由于连锁效应，导致其他部分出现问题。