在具有共享/排他锁的数据库中，当在事务开始时执行 UPDATE 语句时，锁是如何工作的？

【问题标题】：In a database with shared/exclusive locks, when an UPDATE statement is executed at the beginning of the transaction, how do the locks work?在具有共享/排他锁的数据库中，当在事务开始时执行 UPDATE 语句时，锁是如何工作的？
【发布时间】：2021-04-01 00:10:53
【问题描述】：

在具有共享/独占锁的数据库中，当在事务开始时执行 UPDATE 语句时，锁是如何工作的？假设Repeatable Read或更高，它是在读取和搜索阶段获得共享锁，然后是排他锁，还是从一开始就获得排他锁？假设 Read Committed，UPDATE 语句是仅在写入阶段获得排他锁，还是在开始读取时立即获得？我正在使用 PostgreSQL。

【问题讨论】：

我为 Oracle 找到了 dba-oracle.com/t_lock_types.htm，所以我猜测 PostgreSQL 将同样只从执行 UPDATE 语句开始时使用排他锁。在这两种情况下，数据访问都不会因为 MVCC 而减少。我猜如果在执行 UPDATE 语句期间使用共享锁，文档会在postgresql.org/docs/current/explicit-locking.html 中提到它。

标签： database postgresql concurrency locks

【解决方案1】：

当 PostgreSQL 扫描表以查找满足 UPDATE 的 WHERE 条件的行时，它根本不会锁定行。仅当找到候选行时，才会将其锁定为EXCLUSIVE 模式。如果无法立即获得锁，并且UPDATE 被阻塞，PostgreSQL 将等待直到它可以获取锁，然后再次读取该行。行为取决于隔离级别：

与READ COMMITTED，如果最新的行版本仍然满足WHERE条件，则被锁定
使用REPEATABLE READ 或SERIALIZABLE，如果行已更改，则会出现序列化错误并必须重试事务

所有这些is well documented。

【讨论】：