4

以下查询在 1.5 秒内完成（没关系，该表包含大约 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 会将运行时间增加到完全不可接受的 200 秒：

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 倍的时间？

这个查询的另一个有趣的修改是 this.. 而不是 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

4

1 回答 1

2

在您的第一个查询中，计划器采用捷径并使用 sales.productid 上可用的 sales_productid_index，因为它被告知 sales.productid = product.id。在此查询中，与 product 的联接实际上所做的唯一事情是确保表中确实存在 id = 24 的行。

在第二个查询中，此快捷方式不可用。计划者可以选择去product，获取id，然后使用productid上的索引扫描sales，可能会得到类似的性能，但是因为他不知道name='new00000006'会导致id=24，所以他可以'猜猜这条路径会产生多少行销售*。据他所知，他将索引扫描 300M 行销售表的重要部分。

*请注意，在第一个查询中，他猜测 productid=24 将产生 42393 行，而得到 34560 行。考虑到该表有 300M 行，非常接近。

于 2013-12-02T17:29:24.660 回答