问题标签 [query-planner]

我有两个查询做同样的事情。1

2

唯一的区别是第一个IN用于子查询，而第二个用于子查询=ANY(ARRAY())。但是第二个比第一个快大约 10 倍。我跑了解释，我得到了这两个结果：1

2

IN从 doc 来看， or之间没有实质性区别ANY。但是为什么我得到如此不同的结果。在任何情况下它ANY都有优势吗？IN

更新：有人指出这个问题可能与PostgreSQL 中的 IN vs ANY 运算符重复。它们是同一个问题，但是那个问题的答案并没有解决我的问题，因为除了那个答案之外，我还有一个更详细的案例。

但是每个的第二个变体并不等同于另一个。ANY 构造的第二个变体采用一个数组（必须是实际的数组类型），而 IN 的第二个变体采用一个逗号分隔的值列表。这导致传递值的限制不同，在特殊情况下也可能导致不同的查询计划：

https://dba.stackexchange.com/a/125500/3684

将多个值集或数组传递给函数

在我的问题中，这两个问题都不是。我只是将一个数组作为子查询传递。我的情况与第一个 URL 完全相反。我的索引仅用于ANY而不用于IN. 所以基本上，这个答案并没有解决我的问题。

UPDATE2：我更新索引：CREATE INDEX ON "Products_product" USING GIST (state, id, upper((title) :: TEXT) gist_trgm_ops);. 我可以确认两个查询的情况相同，这意味着索引存在那里，但第一个不使用它。

UPDATE3：我只是ARRAY在代码中删除。但结果是一样的。

我认为情况并非如此ANYor ，这只是andANY(ARRAY())之间的区别INANY

当我将下一个查询放入函数时，它会慢 76 倍。计划中的唯一区别是：位图索引扫描 VS 索引扫描

计划1： http ://tatiyants.com/pev/#/plans/plan_1562919134481

计划2： http ://tatiyants.com/pev/#/plans/plan_1562918860704

计划1

计划2

功能：

为什么对于函数内部的查询，过滤是在最后一次子查询扫描时完成的？

有没有可能做一些事情让他们平等地工作？

UPD
服务器版本是PostgreSQL 12beta2
由于 30000 个字符的限制，我在此处和此处发布计划

我有一个需要 20 分钟才能运行的查询，即使我在 where 子句中的每一列都有一个索引，并且每一列都被加入：

这是我的查询计划。

令我困惑的一件事是：如果我添加以下 WHERE 子句，查询会在大约 0.5 秒内返回：

现在您说，well, duh, of course it gets much faster with that- 问题是，ModelImport 表只包含 351 条记录。这意味着如果我将上面的查询拆分为 351 个查询，每个查询都有自己的 where 子句用于不同的 ModelCode - 那么我可以在大约 175 秒或 2.9 分钟内获得 100% 的查询结果。这要快得多。这告诉我，开放式查询中的某些东西效率极低，而且查询计划也很糟糕。

这是我添加的查询计划AND mi.ModelCode = '3FBK5'。

查看我的查询计划后，有什么想法可以加快速度吗？

现在我们更改为 LIMIT 10：

alerts 表有数百万条记录，其他表数以千计。

我已经可以通过简单地不使用 limit < 10 来优化查询。我不明白为什么 LIMIT 会影响性能。也许有比硬编码这个幻数“10”更好的方法。

我对 postgresql 有一个奇怪的问题。Somewhy planner 认为通过外键索引访问数据非常慢，使用顺序扫描。

有一个简化的表结构：

表格passenger大约有 1400 万行，表格飞行大约有 6 万行。

问题是，我有一个带有许多可选条件的 QueryDSL 查询，其中一个是按航班过滤乘客。

当我尝试获取符合这些可选条件的所有乘客时，它会生成如下所示的查询，并执行整整 30 秒。这太可怕了。它以某种方式对所有表使用顺序扫描和散列连接passenger。

但是，经过一天的寻求解决方案，我发现使用flight表的主键会使postgres使用主键索引：

不幸的是，我无法过滤我手动收到的行，因为这将导致约 1300 万行，flightId而设置时每个航班约 300 名乘客。

➥ 所以，我的问题是：有没有办法告诉 QueryDSL/Hibernate 在这种情况下使用特定的列？即flight.id，不是passenger.flight_id。

或者，另一个问题：我的 PostgreSQL 规划器出了什么问题，我该如何解决？

UPD规划师的计划：

• 在 WHERE 条件下使用主键的好查询：

• 在 WHERE 条件下使用外键的错误查询：

我有一个带有外键的表和最近更新行的时间戳。具有相同外键值的行在大致相同的时间更新，正负一个小时。我在（foreign_key，timestamp）上有一个索引。这是在 postgresql 11 上。

当我进行如下查询时：

select * from table where foreign_key = $1 and timestamp > $2 order by primary_key;

如果时间戳查询在整个表中是选择性的，它将使用我的索引。但是如果时间戳在过去足够远以至于大多数行都匹配，它将扫描 primary_key 索引，假设它会更快。如果我删除订单，这个问题就会消失。

我查看了 Postgresql 的CREATE STATISTICS，但在相关性超过一系列值（如时间戳加或减五分钟）而不是特定值的情况下，它似乎没有帮助。

解决此问题的最佳方法是什么？我可以删除订单，但这会使业务逻辑复杂化。我可以根据外键 id 对表进行分区，但这也是一个非常昂贵的更改。

规格：

该表有大约 1600 万行。

然后没有订单：

给定几百万个文档的集合，如下所示：

和 2 个索引，在两个键 {organization: 1} 和 {updated_on: 1}

以下查询需要很长时间才能返回：

需要注意的一件事是，结果是 0 个匹配项。经过进一步调查，explain() 中的规划器实际上返回以下内容：

• 为什么 Mongo 会将这些合并到一个阶段并决定在过滤之前对所有文档进行排序？
• 我怎样才能防止这种情况？

当我尝试验证包含“CREATE TABLE”的 sql 语句时，它会引发错误：

我想知道是否可以在方解石中使用 ddl 语句验证查询？

我正在研究优化 SQL Server 2016 中的一些查询，我遇到了这种我无法理解的情况。

此特定查询试图获取 dbo.Objects 表中两组对象的名称。为此，查询计划显示 SQL 在检索聚集索引后正在使用嵌套循环内连接中的键查找。但是，对较大的对象集进行键查找的估计成本低于对较小对象集的键查找。它们都在同一张表上运行，使用相同的聚集索引进行查找，使用相同的谓词，所以除了行号之外，我看不出还有什么会影响他们的成本估算，但这似乎有相反的结果。

我可以在属性中找到的唯一区别是估计/实际执行，以及估计的重新绑定/倒带。较小的集合估计有 5854 次重新绑定并且没有倒带，而较大的集合估计有 1069.66 次重新绑定和 22356.9 次倒带。但是，我不知道这些在 Key Lookups 的上下文中是什么意思

以下是每个操作的工具提示，以显示我在说什么。

为什么这些运营商可能有如此不同的估计运营商计数？

有一个有趣的问题，我多年来一直在努力解决，并且开始成为一个更大的问题。我们有一个在整个系统中彻底使用的 UDF，并从日志表中检索单个值。它通常会立即运行，但它的查询计划似乎会周期性地发生某些事情，导致它运行几分钟而没有返回。

我们发现，如果我们重新编译 UDF，它会再次工作。

如果我撤回执行计划，我并没有真正得到任何表明索引问题的信息。

编辑：执行计划副本：https ://filebin.net/jlxf0ejqeyz9j9b9

编辑 2：执行计划的屏幕截图：屏幕截图 1：https ://filebin.net/eula7cir72lp95iv/exec-screenshot1.png?t=0i8i2kyj

截图 2：https ://filebin.net/yr2d84x5fftqjvnm/exec-screenshot2.png?t=um9ldpdk

编辑 3：屏幕截图 3 悬停在函数调用上：https ://filebin.net/9azjdvb1mpmsi3am/exec-screenshot3.png?t=qjsemw6d

我们目前有一项工作，它每 30 分钟循环一次并重新编译一次 UDF，我知道这只是一个创可贴解决方案。如果有人对如何进一步调试有一些建议，我将非常感谢您的洞察力！

不幸的是，这个问题并不总是表现出来，所以我们经常不知道它，直到有人指出它。