我尝试执行相同的
UPDATE
查询两次,如下所示。
第一次事务没有锁,但在第二次查询后我可以看到行锁。
架构:
test=# \d t1
Table "public.t1"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
i | integer | | not null |
j | integer | | |
Indexes:
"t1_pkey" PRIMARY KEY, btree (i)
Referenced by:
TABLE "t2" CONSTRAINT "t2_j_fkey" FOREIGN KEY (j) REFERENCES t1(i)
test=# \d t2
Table "public.t2"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
i | integer | | not null |
j | integer | | |
k | integer | | |
Indexes:
"t2_pkey" PRIMARY KEY, btree (i)
Foreign-key constraints:
"t2_j_fkey" FOREIGN KEY (j) REFERENCES t1(i)
现有数据:
test=# SELECT * FROM t1 ORDER BY i;
i | j
---+---
1 | 1
2 | 2
(2 rows)
test=# SELECT * FROM t2 ORDER BY i;
i | j | k
---+---+---
3 | 1 |
4 | 2 |
(2 rows)
更新查询和行锁状态:
test=# BEGIN;
BEGIN
test=# UPDATE t2 SET k = 123 WHERE i = 3;
UPDATE 1
test=# SELECT * FROM t1 AS t, pgrowlocks('t1') AS p WHERE p.locked_row = t.ctid;
i | j | locked_row | locker | multi | xids | modes | pids
---+---+------------+--------+-------+------+-------+------
(0 rows)
test=# UPDATE t2 SET k = 123 WHERE i = 3;
UPDATE 1
test=# SELECT * FROM t1 AS t, pgrowlocks('t1') AS p WHERE p.locked_row = t.ctid;
i | j | locked_row | locker | multi | xids | modes | pids
---+---+------------+--------+-------+----------+-------------------+------
1 | 1 | (0,1) | 107239 | f | {107239} | {"For Key Share"} | {76}
(1 row)
test=#
为什么 postgres 仅在第二次尝试获取行锁?
顺便说一下,更新列 t2.j 的查询会立即在 t1 行上创建新锁(ForKeyShare)。此行为是有意义的,因为 t2.j 具有外键约束引用 t1.i。但上面的查询似乎不是。
谁能解释一下这个锁?
PostgreSQL 版本:9.6.3
好的,我明白了。
https://engineering.nordeus.com/postgres-locking-revealed/
这是 Postgres 中存在的优化。如果锁定管理器可以从第一个查询中确定外键没有更改(更新查询中未提及或设置为相同的值),它将不会锁定父表。但在第二个查询中,它将按照文档中描述的方式运行(它将在 ROW SHARE 锁定模式下锁定父表,并在 FOR SHARE 模式下锁定引用行)
看来 MySQL 对于外键锁更加明智,因为相同的
UPDATE
查询不会在 MySQL 上进行此类锁定。