Fix the word 'concurrency' in chapter 7

This commit is contained in:
mrdrivingduck 2021-01-04 11:25:37 +08:00
parent 7cbc01c00e
commit aa8347b03c
2 changed files with 2 additions and 2 deletions

2
ch7.md
View File

@ -324,7 +324,7 @@ SELECT COUNT*FROM emails WHERE recipient_id = 2 AND unread_flag = true
与读取提交的隔离类似,快照隔离的实现通常使用写锁来防止脏写(请参阅“[读已提交](#读已提交)”),这意味着进行写入的事务会阻止另一个事务修改同一个对象。但是读取不需要任何锁定。从性能的角度来看,快照隔离的一个关键原则是:**读不阻塞写,写不阻塞读**。这允许数据库在处理一致性快照上的长时间查询时,可以正常地同时处理写入操作。且两者间没有任何锁定争用。
为了实现快照隔离,数据库使用了我们看到的用于防止[图7-4]()中的脏读的机制的一般化。数据库必须可能保留一个对象的几个不同的提交版本,因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象,所以这种技术被称为**多版本并发控制MVCC, multi-version concurrentcy control**。
为了实现快照隔离,数据库使用了我们看到的用于防止[图7-4]()中的脏读的机制的一般化。数据库必须可能保留一个对象的几个不同的提交版本,因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象,所以这种技术被称为**多版本并发控制MVCC, multi-version concurrency control**。
如果一个数据库只需要提供**读已提交**的隔离级别,而不提供**快照隔离**那么保留一个对象的两个版本就足够了提交的版本和被覆盖但尚未提交的版本。支持快照隔离的存储引擎通常也使用MVCC来实现**读已提交**隔离级别。一种典型的方法是**读已提交**为每个查询使用单独的快照,而**快照隔离**对整个事务使用相同的快照。

View File

@ -324,7 +324,7 @@ SELECT COUNT*FROM emails WHERE recipient_id = 2 AND unread_flag = true
與讀取提交的隔離類似,快照隔離的實現通常使用寫鎖來防止髒寫(請參閱“[讀已提交](#讀已提交)”),這意味著進行寫入的事務會阻止另一個事務修改同一個物件。但是讀取不需要任何鎖定。從效能的角度來看,快照隔離的一個關鍵原則是:**讀不阻塞寫,寫不阻塞讀**。這允許資料庫在處理一致性快照上的長時間查詢時,可以正常地同時處理寫入操作。且兩者間沒有任何鎖定爭用。
為了實現快照隔離,資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本,因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件,所以這種技術被稱為**多版本併發控制MVCC, multi-version concurrentcy control**。
為了實現快照隔離,資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本,因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件,所以這種技術被稱為**多版本併發控制MVCC, multi-version concurrency control**。
如果一個數據庫只需要提供**讀已提交**的隔離級別,而不提供**快照隔離**那麼保留一個物件的兩個版本就足夠了提交的版本和被覆蓋但尚未提交的版本。支援快照隔離的儲存引擎通常也使用MVCC來實現**讀已提交**隔離級別。一種典型的方法是**讀已提交**為每個查詢使用單獨的快照,而**快照隔離**對整個事務使用相同的快照。