以下查询在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行,非常接近.