测试PostgreSQL行级锁

小咪咪 2022-05-13 16:36 139阅读 0赞

### 1.打开三个psql窗口，连接到postgreSQL数据库 ###

查看窗口连接到的服务进程的pid。

select pg_backend_pid();

![70][]   ![70 1][]   ![70 2][]

### 2.在第一个窗口更新一行数据 ###

mydb=# begin;
    BEGIN
    mydb=# select * from student  where id =1 for update;
    +----+-------+
    | id | name  |
    +----+-------+
    |  1 | April |
    +----+-------+
    (1 行记录)

### 3.在第三个窗口查看数据库中锁的情况 ###

select locktype,relation::regclass, virtualxid, transactionid, virtualtransaction ,pid, mode, granted from pg_locks where pid = 28924;

### ![70 3][] ###

由上图可知：加行锁的过程，不仅会先在表上加表级意向锁，也会在相应的主键上加意向锁。

图中没有显示行锁信息，原因是行锁信息不会记录到共享内存中。如果每个行锁都在内存有一条记录的话，全表更新时，表有多少行，就在内存中有多少条行锁信息，那么内存会吃不消。因此，PostgreSQL在内存中并不记录行锁的信息。

没有行锁的信息，如何知道一个进程被另一个进程的行锁给阻塞了呢？看下面演示。

### 4.在第二个窗口也对更新一行数据 ###

mydb=# begin;
    BEGIN
    mydb=# select * from student  where id =1 for update;

### 5.在第三个窗口查看数据库中锁的情况 ###

select locktype,relation::regclass, virtualxid, transactionid, virtualtransaction ,pid, mode, granted from pg_locks where pid in (28924,2052);

![70 4][]

倒数第三行，2052进程（第二个psql窗口对应的数据库服务进程）申请锁时被阻塞了，这个锁的transactionid为17482328。

倒数第二行，transactionid为17482328的锁，被进程28924持有（第一个psql窗口对应的数据库服务进程）。

行锁的阻塞信息通过“transactionid”类型的锁体现出来。从原理上讲，行锁会在数据行上加上自己的transactionid。另一个进程读到这一行时，如果发现有行锁，会transactionid读出来，然后申请在这个transactionid上加“share”锁。而持有行锁的进程已经在此transactionid上加了“Exclusive”锁，因此后面的进程会被阻塞。

[70]: https://img-blog.csdn.net/20181025143606813?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpeWF6aGVuMjAxMQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 1]: https://img-blog.csdn.net/20181025143634814?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpeWF6aGVuMjAxMQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 2]: /images/20220504/bcfabc6d3bc74b5dba33f9ce1e87dd96.png
[70 3]: /images/20220504/53d5f052b95944a29249613b79fdd3b6.png
[70 4]: /images/20220504/30d972d28b4f4535b5e554ad7049aecd.png