Postgresql Postgres在选择多行时变慢_Postgresql

Postgresql Postgres在选择多行时变慢

postgresql

Postgresql Postgres在选择多行时变慢,postgresql,Postgresql,我正在参加11级博士后考试。我有一个包含1.000.000（100万）行的表，每行的大小为40字节（包含5列）。这等于40MB 当我执行时（通过DBeaver、DataGrid等直接在数据库上执行。-不是通过节点、Python等调用）：第一次需要40秒（即使是第一次也不是很慢） “我的表”的CREATE语句： CREATE TABLE public.my_table_1 ( c1 int8 NOT NULL GENERATED ALWAYS AS IDENTITY, c2 i

我正在参加11级博士后考试。我有一个包含1.000.000（100万）行的表，每行的大小为40字节（包含5列）。这等于40MB

当我执行时（通过DBeaver、DataGrid等直接在数据库上执行。-不是通过节点、Python等调用）：

第一次需要40秒（即使是第一次也不是很慢）

“我的表”的CREATE语句：

CREATE TABLE public.my_table_1 (
    c1 int8 NOT NULL GENERATED ALWAYS AS IDENTITY,
    c2 int8 NOT NULL,
    c3 timestamptz NULL,
    c4 float8 NOT NULL,
    c5 float8 NOT NULL,
    CONSTRAINT my_table_1_pkey PRIMARY KEY (id)
);
CREATE INDEX my_table_1_c3_idx ON public.my_table_1 USING btree (c3);
CREATE UNIQUE INDEX my_table_1_c2_idx ON public.my_table_1 USING btree (c2);

在5个随机表上：解释（分析、缓冲）从[表1…2,3,4,5]中选择*

Seq Scan on table_1  (cost=0.00..666.06 rows=34406 width=41) (actual time=0.125..7.698 rows=34406 loops=1)
  Buffers: shared read=322
Planning Time: 15.521 ms
Execution Time: 10.139 ms

Seq Scan on table_2  (cost=0.00..9734.87 rows=503187 width=41) (actual time=0.103..57.698 rows=503187 loops=1)
  Buffers: shared read=4703
Planning Time: 14.265 ms
Execution Time: 74.240 ms

Seq Scan on table_3  (cost=0.00..3486217.40 rows=180205440 width=41) (actual time=0.022..14988.078 rows=180205379 loops=1)
  Buffers: shared hit=7899 read=1676264
Planning Time: 0.413 ms
Execution Time: 20781.303 ms

Seq Scan on table_4  (cost=0.00..140219.73 rows=7248073 width=41) (actual time=13.638..978.125 rows=7247991 loops=1)
  Buffers: shared hit=7394 read=60345
Planning Time: 0.246 ms
Execution Time: 1264.766 ms

Seq Scan on table_5  (cost=0.00..348132.60 rows=17995260 width=41) (actual time=13.648..2138.741 rows=17995174 loops=1)
  Buffers: shared hit=82 read=168098
Planning Time: 0.339 ms
Execution Time: 2730.355 ms

当我向表_5添加限制1.000.000时（它包含170万行）

当我在两个日期之间添加WHERE子句时（我用DataDog软件监视下面的查询，结果在这里（获取时最大约31K行/秒）：：

表5上的顺序扫描（成本=0.00..438108.90行=17862027宽度=41）（实际时间=0.026..2070.047行=17866766循环=1）过滤器：（'2018-01-01 00:00:00+04'：时区时间戳<匹配日期）和（匹配日期<'2020-01-01 00:00:00+04'：时区时间戳））被筛选器删除的行：128408 缓冲区：共享命中=168180 计划时间：14.820毫秒执行时间：2673.171毫秒所有表在c3列上都有一个唯一的索引

数据库的大小总计约为500GB。该服务器有16个内核和112GB M2内存

我曾尝试优化Postgres系统变量，比如：WorkMem（1GB）、shared_buffer（50GB）、effective_cache_size（20GB），但它似乎没有改变任何东西（我知道设置已经应用了，因为我可以看到服务器分配的空闲内存量有很大的不同）

我知道数据库太大，所有数据都无法存储在内存中。但是我能做些什么来提高查询的性能/速度吗？

确保

CreatedDate

已被索引

确保

CreatedDate

正在使用。这将在存储（仅4字节）和性能方面更加高效，并且您可以使用所有内置和

避免选择*，只选择需要的列

使用。这与性能无关，但可以避免很多歧义

真正的问题可能是您有数千个表，您经常使用这些表将数百个表进行联合。这表明需要重新设计模式以简化查询并获得更好的性能

工会和日期变更检查表明存在大量冗余。也许您已经按日期划分了表。Postgres有自己的内置软件，可能会有所帮助

没有更多的细节，我只能说。也许可以问另一个关于你的模式的问题。

没有看到

解释（分析，缓冲）

，我们所能做的就是推测

但是我们可以做一些很好的推测

在CreatedDate上对索引上的表进行集群。这将允许更有序地访问数据，允许更多的预读（但这对某些类型的存储可能没有多大帮助）。如果表具有较高的写入负载，它们可能无法保持集群状态，因此您可能会偶尔对它们进行重新集群。如果它们是静态的，则这可能是一次性事件

获取更多内存。如果希望执行的操作就像所有数据都在内存中一样，那么将所有数据都放到内存中

获得更快的存储，如一流的SSD。它不如RAM快，但比HDD快得多。

提示：如果您在。。。而且…不是这样表达的。A）听起来你真的需要在该列上建立索引。B）在

YYYY-MM-DD

中使用。这些可以被索引。这里的日期无法排序，对Postgres来说毫无意义。在这里，11月在2月之前，但是在1月之后，或者如果这是DD-MM-YYYY，那么1月11日可能在1月2日之前，这远不是清晰的。M2内存？你的意思是？你能分享

CREATE TABLE

语句吗？@tadman PostgreSQL完全理解“01-01-2019”作为日期的含义，并将基于这种理解使用索引。它参考DateStyle来决定MDY和DMY。1）CreatedDate已经被索引-请检查更新的帖子。2） CreatedDate的列类型是timestamptz-这不正常/最佳吗？3）我需要小表中的所有列。@PabloDK

timestamptz

可以。只是不要将日期和时间存储为字符串。为了让我提供更多帮助，您必须描述为什么要合并100个表。1）因为我只需要从所有给定的表中混合很多子周期。2）但是请告诉我为什么1.000.000行需要40秒才能获取（当每行只有41字节时）？@PabloDK如果您指的是

select*from table

第一次需要40秒，但之后速度非常快，这是因为缓存很冷，或者可能是GUI工具处理和呈现了100万行。在

psql

中尝试。否则，我们需要看到这些表的一个示例是union'd。是的-我是“select*from table”的参考，需要40秒（执行总是需要很长时间）：-）好的-我也将尝试使用psql运行测试。。。否则就没什么可做的了？1）你到底在问什么：解释（分析，缓冲）？我应该执行什么样的SQL语句才能为您提供所需的信息？2）内存是三星m.2 PRO 1TB X 3/我所知道的最快/最好的。。。3）服务器中的主板“仅”允许128GB内存，我已经在所有表上运行了真空+分析-但它没有改变任何东西。@PabloDK

Explain

是找出查询速度慢的原因的基本工具。您可以尝试使用CreatedDate进行

集群，这将在获取CreatedDate范围时对表进行重新排序，以提高效率。表1上的顺序扫描（成本=0.00..20728.58行=1071458宽度=41）表2上的顺序扫描（成本=0.00..328809.16行=16996416宽度=41）表3上的顺序扫描（cost=0.00..78231.31行=4043831宽=41）@PabloDK这些是全表扫描。它没有使用i
Seq Scan on table_1  (cost=0.00..666.06 rows=34406 width=41) (actual time=0.125..7.698 rows=34406 loops=1)
  Buffers: shared read=322
Planning Time: 15.521 ms
Execution Time: 10.139 ms

Seq Scan on table_2  (cost=0.00..9734.87 rows=503187 width=41) (actual time=0.103..57.698 rows=503187 loops=1)
  Buffers: shared read=4703
Planning Time: 14.265 ms
Execution Time: 74.240 ms

Seq Scan on table_3  (cost=0.00..3486217.40 rows=180205440 width=41) (actual time=0.022..14988.078 rows=180205379 loops=1)
  Buffers: shared hit=7899 read=1676264
Planning Time: 0.413 ms
Execution Time: 20781.303 ms

Seq Scan on table_4  (cost=0.00..140219.73 rows=7248073 width=41) (actual time=13.638..978.125 rows=7247991 loops=1)
  Buffers: shared hit=7394 read=60345
Planning Time: 0.246 ms
Execution Time: 1264.766 ms

Seq Scan on table_5  (cost=0.00..348132.60 rows=17995260 width=41) (actual time=13.648..2138.741 rows=17995174 loops=1)
  Buffers: shared hit=82 read=168098
Planning Time: 0.339 ms
Execution Time: 2730.355 ms

Limit  (cost=0.00..19345.79 rows=1000000 width=41) (actual time=0.007..131.939 rows=1000000 loops=1)
  Buffers: shared hit=9346
  ->  Seq Scan on table_5(cost=0.00..348132.60 rows=17995260 width=41) (actual time=0.006..68.635 rows=1000000 loops=1)
        Buffers: shared hit=9346
Planning Time: 0.048 ms
Execution Time: 164.133 ms

Seq Scan on table_5 (cost=0.00..438108.90 rows=17862027 width=41) (actual time=0.026..2070.047 rows=17866766 loops=1)
  Filter: (('2018-01-01 00:00:00+04'::timestamp with time zone < matchdate) AND (matchdate < '2020-01-01 00:00:00+04'::timestamp with time zone))
  Rows Removed by Filter: 128408
  Buffers: shared hit=168180
Planning Time: 14.820 ms
Execution Time: 2673.171 ms