Postgres选择查询具有排他锁性能问题

Question

最近在解决生产错误时，我使用了PostgreSQL独占锁，并且以辛苦的方式学到了教训。仅仅一个简单的锁就严重影响了服务器的性能，我不得不还原代码，同时将错误再次留在系统中。我确定这会影响性能，但不知道其严重性。

10000条查询排它锁花费了[[70毫秒。而没有锁定的相同查询仅花费了[[10毫秒。

我仍然需要解决此问题，并且不知道有更好的机制来解决此问题。有没有一种方法可以提高此类查询的性能。还是我需要寻找替代解决方案？

我确实找到了几篇有关锁对查询的性能影响的文章，但没有什么真正的好！

Answer 1

在我有10000行的简单表上，没有UPDATE子句：

postgres=# explain (analyze,buffers, timing) select * from t ;
                                             QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..198.00 rows=10000 width=8) (actual time=0.060..1.207 rows=10000 loops=1)
   Buffers: shared hit=98
 Planning Time: 0.046 ms
 Execution Time: 1.860 ms
(4 rows)

with FOR UPDATE子句：

postgres=# explain (analyze,buffers, timing) select * from t  for update;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 LockRows  (cost=0.00..298.00 rows=10000 width=14) (actual time=0.066..9.158 rows=10000 loops=1)
   Buffers: shared hit=20098
   ->  Seq Scan on t  (cost=0.00..198.00 rows=10000 width=14) (actual time=0.045..1.474 rows=10000 loops=1)
         Buffers: shared hit=98
 Planning Time: 0.039 ms
 Execution Time: 9.807 ms
(6 rows)

就我而言，使用FOR UPDATE子句的速度要慢9/10倍。

也许需要更多时间，因为似乎您有分区：也许您有更多数据要读取。
您最近是否在这些表上运行VACUUM或ANALYZE吗？
尝试将代码输出作为文本而不是图像输出：比图像更容易阅读文本。
请在会话中以track_io_timing=on发布查询的EXPLAIN（ANALYZE，BUFFERS，TIMING）输出。