当 `my_variable IN (<long_array_of_items>)` 在 PostgreSQL 中速度快时？

Question

我发现自己有时需要根据 id 或其他变量的列表选择不同表的许多项目。鉴于此列表可以包含数千个元素，对我来说重要的是过滤器不会成为 n*m 查询。我经历过，在某些情况下，postgres 会进行快速查找，有时则不会，例如，如果我按主键进行过滤。当过滤速度很慢时，我通常通过创建一个

IN

查询表并将其与该表连接起来以进行过滤来解决它。

但现在我又回到了这个问题，我真的想听听是否有人可以帮助我建立一些直觉，让我知道何时应该使用查找以及何时使用哈希表。

在我目前的工作中，我们使用的是postgres 15，但我的大部分经验都是来自postgres 10，所以可能会有一些旧版本的坏习惯。

Answer 1

如果可以的话为什么要假设

explain analyze verbose

。如果没有看到它取代了什么以及如何取代的示例，就很难评论为什么

IN

工作得这么好。

即使有足够好的直觉来信任它，如果你

信任，但验证，你的情况仍然会更好。服务器配置、索引设置、表大小、流量以及 vacuum analyze

 的频率都会对规划器的结果产生影响，并且它可以更改版本。在这种情况下，所有人类直觉都注定是不可靠的，并且很快就会过时。

话虽如此，

这里有 db<>fiddle 的一些 1M 行测试，这里有一些 in

、

any

、

exists

、

join

 行为

的比较，这里还有 更多、更多视觉.