postgresql – Postgres选择了一个糟糕的查询计划

2023年5月26日 219次阅读

以下查询在1.5s内完成(可以,表包含大约500M行)：

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.id = 24
order by date.timestamp
limit 200;

查询计划：http://explain.depesz.com/s/8Ix

搜索product.name会将运行时间增加到完全不可接受的200s：

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.name = 'new00000006'
order by date.timestamp
limit 200;

查询计划：http://explain.depesz.com/s/0RfQ

请注意,名为“new00000006”的产品具有id 24(与上面的快速查询中的id相同).证明：

select name from product where id = 24;

    name
-------------
 new00000006

为什么该查询比第一个查询长200倍？

这个查询的另一个有趣的修改是..而不是product.id = 24(就像在第一个查询中一样),我使用product.id =(select 24).这也需要200秒才能运行(实际上会导致与搜索product.name时相同的错误查询计划)：

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.id = (select 24)
order by date.timestamp
limit 200;

查询计划：http://explain.depesz.com/s/K3VO

统计表显示产品ID 24“罕见”：

select most_common_vals from pg_stats where tablename='sales' and attname='productid';

{19,2,7,39,40,14,33,18,8,37,16,48,6,23,49,29,46,41,20,53,47,26,38,1,32,42,56,57,10,15,27,50,30,45,51,58,17,36,4,25,44,43,5,22,11,35,52,9,21,12,24,31,28,54,34,3,55,13}

select most_common_freqs from pg_stats where tablename='sales' and attname='productid';

{0.020225,0.020119,0.0201133,0.0201087,0.0201,0.0200903,0.0200843,0.020069,0.0200557,0.0200477,0.0200427,0.0200303,0.0200197,0.020019,0.020012,0.0200107,0.0200067,0.020006,0.019995,0.0199947,0.0199917,0.019986,0.019986,0.0199777,0.0199747,0.0199713,0.0199693,0.019969,0.019967,0.019962,0.0199607,0.0199603,0.01996,0.0199567,0.0199567,0.0199533,0.019952,0.019951,0.0199467,0.019944,0.019944,0.01993,0.0199297,0.0199257,0.0199223,0.0199143,0.01989,0.0198887,0.019883,0.0198747,6.7e-005,6e-005,5.9e-005,5.6e-005,5.46667e-005,5.43333e-005,5.13333e-005,4.96667e-005}

产品ID 24的频率为6.7e-005(它是“新产品”),而旧产品的频率约为0.01.

统计显示第一个查询计划(运行在1.5秒内的计划)非常有意义.它使用sales_productid_index快速查找此产品的销售情况.为什么在其他两种情况下使用的查询计划不一样？似乎忽略了统计数据.

表定义(略微混淆/重命名)：

                            Tabelle äpublic.salesô
  Spalte   |   Typ   | Attribute | Speicherung | Statistikziel | Beschreibung
-----------+---------+-----------+-------------+---------------+--------------
 id        | uuid    | not null  | plain       |               |
 dateid    | integer |           | plain       | 10000         |
 productid | integer |           | plain       | 10000         |
 a         | text    |           | extended    | 10000         |
 b         | integer |           | plain       | 10000         |
 x1        | boolean |           | plain       |               |
 x2        | boolean |           | plain       |               |
 x3        | boolean |           | plain       |               |
 x4        | boolean |           | plain       |               |
 x5        | boolean |           | plain       |               |
Indexe:
    "sales_pkey" PRIMARY KEY, btree (id)
    "sales_a_index" btree (a)
    "sales_b_index" btree (b)
    "sales_dateid_index" btree (dateid)
    "sales_productid_index" btree (productid)
Fremdschlnssel-Constraints:
    "sales_dateid_fkey" FOREIGN KEY (dateid) REFERENCES date(id)
    "sales_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
Hat OIDs: nein

                                                 Tabelle äpublic.productô
 Spalte |   Typ   |                        Attribute                         | Speicherung | Statistikziel | Beschreibung
--------+---------+----------------------------------------------------------+-------------+---------------+--------------
 id     | integer | not null Vorgabewert nextval('product_id_seq'::regclass) | plain       |               |
 name   | text    |                                                          | extended    |               |
Indexe:
    "product_pkey" PRIMARY KEY, btree (id)
    "product_name_index" UNIQUE, btree (name)
Fremdschlnsselverweise von:
    TABLE "sales" CONSTRAINT "sales_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
    TABLE "salesaggr" CONSTRAINT "salesaggr_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
Hat OIDs: nein

版本：PostgreSQL 9.3.1,由Visual C build 1600,64位编译

配置：默认配置,除了maintenance_work_mem,已增加到1GB.

操作系统：Microsoft Windows [版本6.2.9200]

安装RAM的数量和大小：32GB

存储：单个1TB SSD

最佳答案 在您的第一个查询中,计划程序采用快捷方式并使用sales.productid上可用的sales_producti_index,因为它被告知sales.productid = product.id.与产品实际连接的唯一事实是确保表中实际存在id = 24的行.

在第二个查询中,此快捷方式不可用.规划人员可以选择转到产品,获取ID然后使用productid上的索引扫描销售,可能获得类似的性能,但因为他不知道名称=’new00000006’会导致id = 24,他可以’猜猜此路径将导致销售额中的行数*.尽管如此,他知道他将成为300M行销售表中重要部分的索引.

*请注意,在第一个查询中,他猜测productid = 24将导致42393行,而获得34560行.考虑到表有300M行,非常接近.

点赞