我正在使用PostgreSQL 10
这是我的模特：
https://imgur.com/bibWSq8
每个review仅属于一个product。每个product可以属于许多category。每个category只能有一个父级category。
我正在使用Prisma查询数据库。这是一种ORM。
我想从属于review的所有product中选择前10个category，其中id = 27。
这是Prisma生成的查询：
select
"Alias"."id"
from "database"."review" as "Alias"
where ("Alias"."id"
in (select "database"."review"."id"
from "database"."review"
where "database"."review"."product"
in (select "database"."category_to_product"."product"
from "database"."category_to_product"
join "database"."category" as "category_product_Alias"
on "category_product_Alias"."id" = "database"."category_to_product"."category"
where ("category_product_Alias"."id" = 27
or "category_product_Alias"."id"
in (select "database"."category"."id"
from "database"."category"
join "database"."category" as "category_category_product_Alias"
on "category_category_product_Alias"."id" = "database"."category"."parent"
where "category_category_product_Alias"."id" = 27
)
)
)
)
)
order by "Alias"."id" desc
limit 11
offset 0;
有1.500.000 review s，12.000 product s和130 category s。该查询几乎需要3秒钟才能完成。
我尝试创建索引，但是没有用：
CREATE UNIQUE INDEX category_pkey ON "database".category USING btree (id)
CREATE INDEX idx_category_parent ON "database".category USING btree (parent)
CREATE UNIQUE INDEX "category_to_product_AB_unique" ON "database".category_to_product USING btree (category, product)
CREATE INDEX "category_to_product_B" ON "database".category_to_product USING btree (product))
CREATE UNIQUE INDEX product_pkey ON "database".product USING btree (id)
CREATE INDEX idx_review_product ON "database".review USING btree (product)
CREATE UNIQUE INDEX review_pkey ON "database".review USING btree (id)
这是运行explain analyze时的结果：
Limit (cost=9.00..101.89 rows=11 width=4) (actual time=3428.508..3431.048 rows=11 loops=1)
-> Merge Semi Join (cost=9.00..12584725.82 rows=1490226 width=4) (actual time=3428.507..3431.043 rows=11 loops=1)
Merge Cond: ("Alias".id = review.id)
-> Index Only Scan Backward using review_pkey on review "Alias" (cost=0.43..84869.82 rows=1490226 width=4) (actual time=0.008..152.954 rows=1054436 loops=1)
Heap Fetches: 0
-> Nested Loop Semi Join (cost=8.57..12477502.61 rows=1490226 width=4) (actual time=3188.974..3191.303 rows=11 loops=1)
-> Index Scan Backward using review_pkey on review (cost=0.43..266561.32 rows=1490226 width=8) (actual time=0.004..415.244 rows=1054436 loops=1)
-> Nested Loop (cost=8.14..8.18 rows=1 width=4) (actual time=0.002..0.002 rows=0 loops=1054436)
-> Index Scan using "category_to_product_B" on category_to_product (cost=0.29..0.30 rows=1 width=8) (actual time=0.001..0.001 rows=1 loops=1054436)
Index Cond: (product = review.product)
-> Index Only Scan using category_pkey on category "category_product_Alias" (cost=7.86..7.88 rows=1 width=4) (actual time=0.001..0.001 rows=0 loops=1084175)
Index Cond: (id = category_to_product.category)
Filter: ((id = 27) OR (hashed SubPlan 1))
Rows Removed by Filter: 1
Heap Fetches: 0
SubPlan 1
-> Nested Loop (cost=0.00..7.71 rows=1 width=4) (actual time=0.016..0.016 rows=0 loops=1)
-> Seq Scan on category (cost=0.00..3.85 rows=1 width=8) (actual time=0.015..0.016 rows=0 loops=1)
Filter: (parent = 27)
Rows Removed by Filter: 148
-> Seq Scan on category "category_category_product_Alias" (cost=0.00..3.85 rows=1 width=4) (never executed)
Filter: (id = 27)
Planning time: 0.649 ms
Execution time: 3431.098 ms
我认为我的数据不是太大，但是查询太慢。有什么方法可以使其更快？
更新1 我只是使用@Laurenz Albe的方法，速度更快。这是结果
Limit (cost=217773.56..217773.59 rows=11 width=8) (actual time=735.033..735.041 rows=11 loops=1)
-> Sort (cost=217773.56..221499.13 rows=1490226 width=8) (actual time=735.031..735.033 rows=11 loops=1)
Sort Key: (("Alias".id + 0)) DESC
Sort Method: top-N heapsort Memory: 25kB
-> Hash Semi Join (cost=99929.33..184545.76 rows=1490226 width=8) (actual time=354.030..733.405 rows=13589 loops=1)
Hash Cond: ("Alias".id = review.id)
-> Seq Scan on review "Alias" (cost=0.00..60400.26 rows=1490226 width=4) (actual time=0.005..157.747 rows=1482065 loops=1)
-> Hash (cost=81301.50..81301.50 rows=1490226 width=4) (actual time=350.842..350.842 rows=13589 loops=1)
Buckets: 2097152 Batches: 1 Memory Usage: 16862kB
-> Hash Join (cost=410.63..81301.50 rows=1490226 width=4) (actual time=3.363..347.392 rows=13589 loops=1)
Hash Cond: (review.product = category_to_product.product)
-> Seq Scan on review (cost=0.00..60400.26 rows=1490226 width=8) (actual time=0.011..144.852 rows=1482065 loops=1)
-> Hash (cost=326.86..326.86 rows=6702 width=4) (actual time=2.121..2.121 rows=100 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 68kB
-> HashAggregate (cost=259.84..326.86 rows=6702 width=4) (actual time=2.064..2.103 rows=100 loops=1)
Group Key: category_to_product.product
-> Hash Join (cost=12.86..243.08 rows=6702 width=4) (actual time=0.336..2.026 rows=100 loops=1)
Hash Cond: (category_to_product.category = "category_product_Alias".id)
-> Seq Scan on category_to_product (cost=0.00..194.03 rows=13403 width=8) (actual time=0.004..0.873 rows=12063 loops=1)
-> Hash (cost=11.93..11.93 rows=74 width=4) (actual time=0.037..0.037 rows=1 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Seq Scan on category "category_product_Alias" (cost=7.71..11.93 rows=74 width=4) (actual time=0.025..0.035 rows=1 loops=1)
Filter: ((id = 27) OR (hashed SubPlan 1))
Rows Removed by Filter: 147
SubPlan 1
-> Nested Loop (cost=0.00..7.71 rows=1 width=4) (actual time=0.015..0.015 rows=0 loops=1)
-> Seq Scan on category (cost=0.00..3.85 rows=1 width=8) (actual time=0.015..0.015 rows=0 loops=1)
Filter: (parent = 27)
Rows Removed by Filter: 148
-> Seq Scan on category "category_category_product_Alias" (cost=0.00..3.85 rows=1 width=4) (never executed)
Filter: (id = 27)
Planning time: 0.591 ms
Execution time: 735.127 ms
更新2 我试图简化查询：
explain analyze select
"review"."id"
from "review"
where "review"."product" in
(
select "category_to_product"."product"
from "category_to_product"
join "category"
on "category"."id" = "category_to_product"."category"
where "category"."id" = 27 or "category"."parent" = 27
)
order by "reviewty$dev"."review"."id" desc
limit 11
offset 0;
但是结果不会改变太多
Limit (cost=0.86..456.52 rows=11 width=4) (actual time=3354.756..3357.181 rows=11 loops=1)
-> Nested Loop Semi Join (cost=0.86..1019733.07 rows=24617 width=4) (actual time=3354.754..3357.176 rows=11 loops=1)
-> Index Scan Backward using review_pkey on review (cost=0.43..266561.32 rows=1490226 width=8) (actual time=0.007..391.076 rows=1054436 loops=1)
-> Nested Loop (cost=0.43..0.50 rows=1 width=4) (actual time=0.002..0.002 rows=0 loops=1054436)
-> Index Scan using "category_to_product_B" on category_to_product (cost=0.29..0.30 rows=1 width=8) (actual time=0.001..0.001 rows=1 loops=1054436)
Index Cond: (product = review.product)
-> Index Scan using category_pkey on category (cost=0.14..0.17 rows=1 width=4) (actual time=0.001..0.001 rows=0 loops=1084175)
Index Cond: (id = category_to_product.category)
Filter: ((id = 27) OR (parent = 27))
Rows Removed by Filter: 1
Planning time: 0.434 ms
Execution time: 3357.210 ms
我现在唯一的方法是在+ 0之后附加order by "Alias"."id"。真可悲，正如我所说，该查询是由Prisma（prisma.io）生成的，而不是由我生成的，我想编写本机sql。
更新3
@Ancoron是正确的，set enable_nestloop = off在运行查询之前将使其更快。它强制PostgreSQL使用hash join而不是nested loop。
Limit (cost=10000238022.63..10000238023.45 rows=11 width=4) (actual time=629.606..629.804 rows=11 loops=1)
-> Merge Semi Join (cost=10000238022.63..10000348970.97 rows=1490226 width=4) (actual time=629.605..629.797 rows=11 loops=1)
Merge Cond: ("Alias".id = review.id)
-> Index Only Scan Backward using review_pkey on review "Alias" (cost=0.43..84869.82 rows=1490226 width=4) (actual time=0.006..152.252 rows=1054436 loops=1)
Heap Fetches: 0
-> Sort (cost=10000238022.20..10000241747.77 rows=1490226 width=4) (actual time=390.996..391.000 rows=11 loops=1)
Sort Key: review.id DESC
Sort Method: quicksort Memory: 1021kB
-> Hash Semi Join (cost=10000000604.70..10000085221.14 rows=1490226 width=4) (actual time=4.306..388.164 rows=13589 loops=1)
Hash Cond: (review.product = category_to_product.product)
-> Seq Scan on review (cost=0.00..60400.26 rows=1490226 width=8) (actual time=0.004..157.976 rows=1482065 loops=1)
-> Hash (cost=10000000529.30..10000000529.30 rows=6032 width=4) (actual time=0.617..0.617 rows=100 loops=1)
Buckets: 8192 Batches: 1 Memory Usage: 68kB
-> Merge Join (cost=10000000008.29..10000000529.30 rows=6032 width=4) (actual time=0.555..0.603 rows=100 loops=1)
Merge Cond: (category_to_product.category = "category_product_Alias".id)
-> Index Only Scan using "category_to_product_AB_unique" on category_to_product (cost=0.29..419.82 rows=12063 width=8) (actual time=0.007..0.374 rows=2272 loops=1)
Heap Fetches: 1123
-> Index Only Scan using category_pkey on category "category_product_Alias" (cost=10000000007.86..10000000018.82 rows=74 width=4) (actual time=0.024..0.035 rows=1 loops=1)
Filter: ((id = 27) OR (hashed SubPlan 1))
Rows Removed by Filter: 147
Heap Fetches: 0
SubPlan 1
-> Nested Loop (cost=10000000000.00..10000000007.71 rows=1 width=4) (actual time=0.015..0.015 rows=0 loops=1)
-> Seq Scan on category (cost=0.00..3.85 rows=1 width=8) (actual time=0.015..0.015 rows=0 loops=1)
Filter: (parent = 27)
Rows Removed by Filter: 148
-> Seq Scan on category "category_category_product_Alias" (cost=0.00..3.85 rows=1 width=4) (never executed)
Filter: (id = 27)
Planning time: 0.594 ms
Execution time: 629.857 ms
但是我问自己，为什么我必须这样做，PostgreSQL选择了错误的计划，它使用嵌套循环而不是哈希联接，这使查询速度变慢。它是成熟的数据库，所以我认为这是我的问题，当查询速度很慢时，我尝试创建索引，重写查询，以希望PostgreSQL改变其计划，但事实并非如此。可以接受吗？另一件事，我确定我的查询在每种情况下都会运行得更快。 这是我的Prisma查询：
# Write your query or mutation here
query {
reviews (where: {
product:{
categories_some: {
OR:[
{
id: 27
},
{
parent: {
id: 27
}
}
]
}
}
}, orderBy:id_DESC, first:11, skip:0){
id
}
}
我找不到其他方法来更改Prisma查询。
答案 0 :(得分：0)
我的猜测是，由于表中行的敌对分布，当PostgreSQL尝试使用索引扫描来获取正确的顺序时，有趣的行排在最后。
通过将ORDER BY子句更改为
ORDER BY "Alias".id + 0 DESC
“对手分发”是什么意思？根据估计，PostgreSQL认为有很多行可以满足该条件，因此认为以降序Alias.id处理行并一直进行到找到11行为止，这是最便宜的。满足条件。即使猜测是正确的，也可能是满足条件的（许多）行都具有较低的Alias.id，因此它必须以比讨价还价的方式计算更多的行。
看到您的第二个执行计划，我怀疑问题的至少部分原因是PostgreSQL高估了满足条件的行数：1490226而不是13589行。简化查询可能会有所帮助。
答案 1 :(得分：0)
您还可以在运行查询之前使用SET enable_nestloop = off禁用嵌套循环联接（如果可能，则可以在IDSA中使用IDK）。
与ORDER BY ... + 0 DESC相比，这给我带来了更好的执行时间，而根本没有修改查询：https://explain.depesz.com/s/Mi4W
我创建了一个完整的在线示例，其中数据集略有减少（但仍需要一段时间才能加载）以测试不同的查询：https://dbfiddle.uk/?rdbms=postgres_10&fiddle=2c4d104804f57e1a59f7ed31bd57e2f5
如果您使用的是prisma，则最好共享一个来自客户端的prisma请求，该请求来自此SQL查询。也许在这方面也可以做些什么。
从查询角度看，使用CTE的优化围栏可能会提供最佳结果：
WITH
cte_reviews (id) AS (
SELECT r.id
FROM review AS r
INNER JOIN category_to_product AS cp ON (r.product = cp.product)
WHERE
cp.category IN (
SELECT 27
UNION ALL
SELECT id FROM category WHERE parent = 27
)
ORDER BY 1 ASC
)
SELECT id
FROM cte_reviews
ORDER BY id DESC
LIMIT 11 OFFSET 0;
因此，在这里，我们执行正向索引（仅）扫描，然后反向并限制其结果，在这种特殊情况下，这要快得多。
大约22毫秒：
Planning time: 0.577 ms
Execution time: 22.021 ms