9.6 升级后 postgresql IN 查询出现奇怪的性能问题

Weird performance issue on postgresql IN queries after 9.6 upgrade

我们有一个数据库目前 运行 正在 Postgresql 9.5.4 上的 AWS RDS 中运行,我们正在尝试将其升级到 运行 9.6.6。升级后我们遇到了奇怪的性能下降,即使在(我们认为)成功地将所有 postgres 设置复制到 RDS 参数组之后,下面的查询似乎是 "smoking gun",尽管我们没有不是很懂

在我们的 9.5.4 实例上,下面的查询全部 运行 很快(如您所料,假设 uuidaccount_id 列已编入索引):

production=> \timing 
Timing is on.
production=> SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1;
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 3.015 ms
production=> SELECT uuid FROM address WHERE uuid IN ('4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0');
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 0.886 ms
production=>  SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                 uuid                 
--------------------------------------
 4c52c1fb-a344-4ea4-90f8-2f7f9b2cdce0
(1 row)

Time: 2.431 ms

一旦我们将该数据库升级到 9.6.6,前两个查询仍然很快,但最后一个变得非常慢:

production=> \timing 
Timing is on.
production=> SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1;
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 0.732 ms
production=> SELECT uuid FROM address WHERE uuid IN ('747b4b38-81f3-487e-8202-06c964e7e9f8');
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 0.715 ms
production=> SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                 uuid                 
--------------------------------------
 747b4b38-81f3-487e-8202-06c964e7e9f8
(1 row)

Time: 6676.759 ms

在 9.6.6 框上,查询计划器没有提供任何提示(至少,我可以看到):

production=> EXPLAIN SELECT uuid FROM address WHERE uuid IN (SELECT uuid FROM address WHERE account_id = 'Demo' LIMIT 1);
                                                                   QUERY PLAN                                                                    
-------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=5.23..13.27 rows=1 width=16)
   ->  HashAggregate  (cost=4.67..4.68 rows=1 width=16)
         Group Key: address_1.uuid
         ->  Limit  (cost=0.56..4.66 rows=1 width=16)
               ->  Index Scan using address_account_id on address address_1  (cost=0.56..725.46 rows=177 width=16)
                     Index Cond: ((account_id)::text = 'Demo'::text)
   ->  Index Only Scan using address_pkey1 on address  (cost=0.56..8.58 rows=1 width=16)
         Index Cond: (uuid = address_1.uuid)
(8 rows)

此外,运行宁标准 pgbench 对两个盒子的测试实际上表明 9.6.6 盒子在每秒事务处理方面优于 9.5.4 盒子,所以我不认为那里发生了一些奇怪的硬件事情。

想知道是否有人对第三个查询的性能奇怪下降可能来自何处有任何想法?

原来这是因为在 9.5 -> 9.6 升级后,您需要 ANALYZE 整个数据库才能让查询规划器再次运行。