我在 Postgresql 8.4.12 中有下表:
Table "public.ratings"
Column | Type | Modifiers
--------+------------------------+-----------
userid | character varying(128) |
item | character varying(128) |
score | integer |
Indexes:
"ratings_item" btree (item)
"ratings_ui" btree (userid, item)
"ratings_userid" btree (userid)
我想执行自联接来查找对特定项目进行评分的所有用户评分的项目。为了简单起见,我将使用查询来获取每个可疑相似项目的评分数量,如下所示;
select r2.item,sum(1)
from ratings r1
left join ratings r2 using (userid)
where r1.item='an3.php'
group by r2.item
该查询有效,但对于包含 3600 万条记录的表来说,它需要很长时间。当我解释该声明时,我得到以下信息:
GroupAggregate (cost=8102958.42..8247621.18 rows=16978 width=17) -> Sort (cost=8102958.42..8151108.60 rows=19260072 width=17)
Sort Key: r2.item
-> Hash Left Join (cost=1458652.29..4192647.43 rows=19260072 width=17)
Hash Cond: ((r1.userid)::text = (r2.userid)::text)
-> Bitmap Heap Scan on ratings r1 (cost=868.20..77197.24 rows=24509 width
=22)
Recheck Cond: ((item)::text = 'an3.php'::text)
-> Bitmap Index Scan on ratings_item (cost=0.00..862.07 rows=24509 width=0)
Index Cond: ((item)::text = 'an3.php'::text)
-> Hash (cost=711028.93..711028.93 rows=36763293 width=39)
-> Seq Scan on ratings r2 (cost=0.00..711028.93 rows=36763293 width
=39)
根据经验,我认为“对评级 r2 进行序列扫描”是罪魁祸首。
另一方面,如果我搜索不存在的项目:
select r2.item,sum(1) from ratings r1 left join ratings r2 using (userid)
where r1.item='targetitem' group by r2.item;
它似乎工作正常(即没有返回结果并且是立即返回的)
GroupAggregate (cost=2235887.19..2248234.70 rows=16978 width=17) -> Sort (cost=2235887.19..2239932.29 rows=1618038 width=17)
Sort Key: r2.item
-> Nested Loop Left Join (cost=0.00..1969469.94 rows=1618038 width=17)
-> Index Scan using ratings_item on ratings r1 (cost=0.00..8317.74 rows=2 059 width=22)
Index Cond: ((item)::text = 'targetitem'::text)
-> Index Scan using ratings_userid on ratings r2 (cost=0.00..947.24 rows= 419 width=39)
Index Cond: ((r1.userid)::text = (r2.userid)::text)
相同的表和查询在 MySQL 中运行良好,但我无法将我的推荐系统迁移到另一个数据库。
我做错了什么还是Postgres出了问题?有解决办法吗?
最佳答案
回答标题中的(反问)问题:否。
我在这里看到很多问题,从第一行开始。
Postgres 8.4 has reached EOL last year 。没有人应该再使用它了,它太旧了。如果可能的话,升级到当前版本。
除此之外,您至少应该使用最新的次要版本。 8.4.12 于 2012 年 6 月 4 日发布,缺少两年的错误和安全修复。 8.2.23 是死版本的最后一个版本。
Read the versioning policy of the project.
接下来,varchar(128)
作为 PK/FK 效率非常低,尤其是对于具有数百万行的表。处理起来不必要地大且昂贵。使用integer
or bigint
反而。或UUID
如果你真的需要更大的数字空间(我对此表示怀疑)。
接下来,我在 (userid, item)
( which would obsolete an additional index on the same ) 上没有看到 UNIQUE
或 PRIMARY KEY
约束。要么您的表定义缺失,要么您的查询错误,要么您的问题被破坏。
尝试这个重写的查询:
SELECT r2.item, count(*) AS ct
FROM (
SELECT userid
FROM ratings
WHERE item = 'an3.php'
GROUP BY 1 -- should not be necessary, but constraint is missing
) r1
JOIN ratings r2 USING (userid)
GROUP BY 1;
在现代 Postgres 中,您需要两个索引才能获得最佳性能。关于(item,userid)
和(userid,item)
。
在 Postgres 9.2+ 中,您甚至可能从中获得仅索引扫描。我不知道如何充分利用过时的版本。无论哪种方式,varchar(128)
对于索引来说也是一种昂贵的数据类型。
关于sql - PostgreSQL 自连接会忽略索引吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30766937/