系统设计DDIA之Chapter 7 Transactions 之弱隔离级别读已提交

数据库使用弱隔离级别来在提供一定程度的并发问题防护的同时，提高性能。与提供严格隔离的可序列化隔离级别不同，弱隔离级别不保证所有类型的并发问题都被避免，但它们通常足够满足许多应用的需求，并且性能开销较低。

读已提交是最基本的弱隔离级别之一，它提供了两个主要保证：

1. 无脏读：一个事务只能读取已提交的数据，防止读取到另一个未提交的事务所做的更改。
2. 无脏写：一个事务只能覆盖已提交的数据，防止覆盖另一个未提交的事务所做的更改。

在实现“读已提交”隔离级别时，数据库通常使用行级锁来防止脏写，并使用**多版本并发控制（MVCC）**来防止脏读。MVCC 通过维护多个数据版本（已提交的旧值和未提交的新值），确保在一个事务进行时，其他事务可以继续读取旧值，从而避免了性能问题。

使用弱隔离级别的优点在于，它们在保持较高性能的同时，防止了一些常见的并发问题。然而，开发人员需要了解这些隔离级别的局限性，以确保应用程序的可靠性和数据一致性。

Weak Isolation Levels:

Databases use weak isolation levels to improve performance while providing some degree of protection against concurrency issues. Unlike the strict isolation provided by serializable isolation levels, weak isolation levels do not guarantee that all types of concurrency problems are avoided, but they are often sufficient for many applications with lower performance overhead.

Read Committed is one of the most basic weak isolation levels, and it provides two main guarantees:

1. No Dirty Reads: A transaction can only read committed data, preventing it from seeing changes made by another transaction that has not yet committed.
2. No Dirty Writes: A transaction can only overwrite committed data, preventing it from overwriting changes made by another transaction that has not yet committed.

To implement the "read committed" isolation level, databases typically use row-level locks to prevent dirty writes and employ multi-version concurrency control (MVCC) to prevent dirty reads. MVCC maintains multiple versions of data (both old committed values and new uncommitted values), ensuring that while one transaction is in progress, others can continue reading the old values, avoiding performance issues.

The advantage of using weak isolation levels is that they prevent some common concurrency problems while maintaining high performance. However, developers need to be aware of their limitations to ensure the reliability and consistency of their applications.

问题列表和精炼答案

1. 什么是弱隔离级别，为什么数据库使用它们？

   • 回答：弱隔离级别提供了有限的事务隔离，防止某些类型的并发问题，但不保证所有问题都被避免。与可序列化隔离不同，弱隔离级别允许一定程度的并发来提高性能。
     使用原因：完全的事务隔离（如可序列化）需要很高的性能开销，因为它需要严格控制操作顺序和锁定。为了避免这种开销，数据库通常使用弱隔离级别，在提高性能的同时，防止一些常见的并发问题。此外，在许多应用程序中，弱隔离级别足够维持数据一致性和正确性，尤其是在完美的隔离不是必需的情况下。

2. “读已提交”隔离级别提供了哪两个主要保证？

   • 回答：
     1. 无脏读：读取数据时，只能看到已提交的数据，防止事务读取到其他事务尚未提交的更改。
     2. 无脏写：写入数据时，只能覆盖已提交的数据，防止事务覆盖另一个未提交事务的更改。

3. 什么是脏读，“读已提交”隔离级别为什么要防止它？

   • 回答：脏读是指一个事务读取了另一个尚未提交的事务写入的数据。如果第一个事务稍后回滚，那么第二个事务基于未提交数据的操作将变得无效。
     防止原因：防止脏读确保事务只处理已确认和稳定的数据。如果允许脏读，事务可能会基于不完整或未最终确定的数据做出决策，导致错误或意外的结果。防止脏读有助于维持数据的完整性和一致性。

4. 什么是脏写，“读已提交”隔离级别如何处理它？

   • 回答：脏写是指一个事务覆盖了另一个事务尚未提交的数据。“读已提交”通过在写入数据时要求获取写锁来防止脏写。一个事务要修改数据，必须先获取该数据的写锁，直到事务提交或回滚，才释放锁，确保不会发生脏写。

5. 数据库通常如何实现“读已提交”隔离级别以防止脏写？

   • 回答：数据库通常使用行级锁来防止脏写。当一个事务想要修改数据时，它必须首先获取该数据的写锁。在这个锁被释放之前，其他任何事务都不能写入相同的数据。通过这种方式，“读已提交”隔离级别确保了不会有两个事务同时写入相同的数据，防止了脏写。

6. 为什么在实践中使用读锁来防止脏读不是一个理想的解决方案？

   • 回答：使用读锁会显著降低读密集型应用程序的性能。因为即使只有读取操作也需要获取锁，这会导致其他读事务等待锁的释放，从而延迟系统的响应时间。由于并发读取不改变数据，因此没有必要防止多个读取操作同时发生。

7. 大多数数据库如何在最小化对只读事务影响的情况下防止脏读？

   • 回答：大多数数据库使用**多版本并发控制（MVCC）**机制来防止脏读。在这种机制下，数据库为每个数据对象维护多个版本：旧的已提交值和新的未提交值。在一个事务进行中，其他事务可以继续读取旧的已提交值，从而防止脏读而无需使用读锁。

---

Question List and Refined Answers (English)

1. What are weak isolation levels, and why are they used in databases?

   • Answer: Weak isolation levels provide limited isolation for transactions, protecting against some types of concurrency issues but not all. Unlike serializable isolation, which guarantees that transactions are executed as if they were run one at a time, weak isolation levels allow for some concurrency to improve performance.
     Why They Are Used: Full transaction isolation (serializability) has a high performance cost because it requires strict control over the order of operations and locks. To avoid this overhead, databases often use weaker isolation levels that offer better performance while still preventing some common concurrency problems. Additionally, in many applications, weaker isolation levels are sufficient to maintain acceptable levels of consistency and correctness, especially when perfect isolation is not necessary.

2. What are the two main guarantees provided by the "read committed" isolation level?

   • Answer:
     1. No Dirty Reads: When reading data, only committed data will be returned, preventing a transaction from reading changes made by another transaction that has not yet committed.
     2. No Dirty Writes: When writing data, only committed data will be overwritten, preventing a transaction from overwriting changes made by another transaction that has not yet committed.

3. What is a dirty read, and why does the "read committed" isolation level prevent it?

   • Answer: A dirty read occurs when a transaction reads data written by another transaction that has not yet been committed. If the first transaction later rolls back, any data read by the second transaction becomes invalid.
     Why It Is Prevented: Preventing dirty reads ensures that transactions only operate on confirmed and stable data. If dirty reads were allowed, a transaction could make decisions based on incomplete or tentative data, leading to incorrect or unexpected results. Preventing dirty reads helps maintain data integrity and consistency.

4. What is a dirty write, and how does the "read committed" isolation level handle it?

   • Answer: A dirty write occurs when a transaction overwrites data that another transaction has written but not yet committed. The "read committed" isolation level prevents dirty writes by requiring a transaction to acquire a write lock before modifying any data. The lock is held until the transaction commits or aborts, ensuring that no dirty writes occur.

5. How do databases typically implement the "read committed" isolation level to prevent dirty writes?

   • Answer: Databases typically use row-level locks to prevent dirty writes. When a transaction wants to modify data, it must first acquire a write lock on that data. No other transaction can write to the same data until the lock is released. This ensures that no two transactions can simultaneously write to the same data, preventing dirty writes.

6. Why is using read locks not an ideal solution for preventing dirty reads in practice?

   • Answer: Using read locks can significantly degrade performance in read-heavy applications. Because even read operations would need to acquire a lock, other read transactions would have to wait for the lock to be released, delaying the system's response time. Since concurrent reads do not change the data, there is no need to prevent multiple read operations from happening simultaneously.

7. How do most databases prevent dirty reads while minimizing the impact on read-only transactions?

   • Answer: Most databases use multi-version concurrency control (MVCC) to prevent dirty reads. With MVCC, the database maintains multiple versions of each data item: the old committed value and any new uncommitted values. While a transaction is in progress, other transactions continue to read the old committed value, preventing dirty reads without requiring read locks.