0

有两台结构和配置相同的数据库机器，具有以下特点。数据库的结构和内容也相同。几乎 99% 的查询在新机器上的性能更好，只有少数是急剧下降的。试图缩小调查范围，我终于发现只有一个 KNN（K Nearest Neighbour）查询是真正的罪犯。以下是有关“地图”表（约 820k 行）的相关信息：

\d maps
                     Table "maps"
   Column   |       Type        | Collation | Nullable |                       
------------+-------------------+-----------+----------
 id         | integer           |           | not null | 
 strada     | character varying |           |          | 
(...)

 the_geom   | geography         |           |          | 
 concat_all | character varying |           |          | 
(...)

Indexes:
    "pk_maps" PRIMARY KEY, btree (id), tablespace "maps_idx"
    "ggx_maps_the_geom" gist (the_geom) WITH (fillfactor='100', buffering='on'), tablespace "maps_idx"
    "ix_maps_strada" hash (strada), tablespace "maps_idx"

Tablespace: "maps_data"

在下面的“解释分析”调查中，我使用了一个“点”进行测试（实际上除了一个长的不相关的字符串，为了方便起见，只是用“点”替换并由“缓冲区”中的 st_buffer 转换）

EXPLAIN ANALYZE
  SELECT *
  FROM maps m
  WHERE st_buffer('point'::GEOGRAPHY,100::DOUBLE PRECISION) && m.the_geom
  ORDER BY m.the_geom<->'point'::GEOGRAPHY
  LIMIT 1;

以下是实际的机器响应：

（机器#1：16CPU | 64GB RAM | Linux Ubuntu 16.04.7 LTS | PostgreSQL 9.6.21）

 Limit  (cost=0.29..1.96 rows=1 width=711) (actual time=1.306..1.306 rows=1 loops=1)
   ->  Index Scan using ggx_maps_the_geom on maps m  (cost=0.29..1.96 rows=1 width=711) (actual time=1.305..1.305 rows=1 loops=1)
         Index Cond: ('buffer'::geography && the_geom)
         Order By: (the_geom <-> 'point'::geography)
 Planning time: 2.977 ms
 Execution time: 1.480 ms
(6 rows)
Time: **6.885 ms**

（机器#2：16CPU | 64GB RAM | Linux Ubuntu 20.04.2 LTS | PostgreSQL 13.2）

 Limit  (cost=0.29..1.96 rows=1 width=692) (actual time=66.421..66.422 rows=1 loops=1)
   ->  Index Scan using ggx_maps_the_geom on maps m  (cost=0.29..1.96 rows=1 width=692) (actual time=66.420..66.420 rows=1 loops=1)
         Index Cond: (the_geom && 'buffer'::geography)
         Order By: (the_geom <-> 'point'::geography)
 Planning Time: 20.289 ms
 Execution Time: 66.477 ms
(6 rows)
Time: **88.116 ms** (!)

可以看出，机器#2 的性能急剧下降，尽管事实上这两台机器在所有方面都是相同的，包括配置也是如此。有谁知道如何处理这个问题？要检查什么以获得一些线索？

4

0 回答 0