问题标签 [query-planner]

Sales.SalesOrderDetail数据库中有一个表AdventureWorks2014。

我有两个疑问：

和：

查询计划：

可以在此处查看 Brentozar.com 上的查询计划。

和索引：

和聚集索引看起来像这样：

我的问题是为什么查询优化器更喜欢另一个索引 PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID 而不是IX_SalesOrderDetail_ProductID？

我有两个使用中间映射表加入的大表（下面的结构细节）。

我正在尝试加入所有t1.date = t2.date三个t1.id_a = int.id_aint.id_b = t2.id_b

我还有一个 where 子句，它将数据限制在日期列的一个非常特定的范围内（结果集是~25k rows）。

运行表 1 和 int 表的连接（使用 where 子句）或表 2 和 int 表的连接（使用 where 子句）每个都需要 2 秒。然后连接这两个结果集应该很简单，表 1 大约有 37k 行，表 2 大约有 200k 行。

相反，此查询始终需要 8 分钟：

在估计的（和实际的）执行计划中，SQL Server 说它会：

1. 在 t1 上寻找聚集索引，寻找我的日期范围（成本 33%）
2. 计算标量 t.id_a（成本 0%）
3. 在 t2 上寻找聚集索引，寻找我的日期范围（成本 33%）
4. 连接 [2] 和 [3] 的嵌套循环（成本 0%）
5. 在 t_int 上寻找非聚集索引，寻找 t_int.id_a = t1.id_a 和 t_int.id_b = t2.id_b（成本 33%）
6. 连接 [4] 和 [5] 的嵌套循环（成本 0%）
7. 计算标量 t.date、t_int.id_b（成本 0%）

（3.2m 行，date 和 id_a 是主键 w 聚集索引）

（1850 万行，日期和 id_b 是主键 w 聚集索引）

映射表：

（35k 行，id_b 是主键 w 聚集索引，[ id_a, id_b, other_col] 上的附加非聚集索引）

没有其他索引，也没有任何约束（除了提到的主键约束）。

我已经在 t2 上重建了索引

任何人都可以帮助我需要做的事情吗？

我有一个带有“或”语句和“内部选择”语句的查询。当我检查查询计划时，它使用全表访问，我不知道为什么会发生这种情况。

我创建了这个测试用例来显示我的问题：

这是有问题的查询：

当我分析查询计划时，我看到它对人员表使用全表访问。这大大减慢了我的查询时间，我不知道为什么会这样。

如果我消除第一个约束（p.NAME = 'name300'）并仅使用 subselect 语句进行查询，则一切正常，查询再次使用索引。

有人可以解释一下为什么查询没有在第一种情况下使用我的索引吗？

我有一个没有意义的计划的简单 Oracle 查询。

这是自动跟踪解释告诉我的计划

我关心的是谓词 3. sort_type没有出现在查询中，并且根本没有被索引。在我看来，sort_type根本不应该参与这个查询。

有一个限制：（是的，我知道我们可能是整数而不是数字）lists.sort_typesort_type

在我看来，那个过滤器sort_type基本上是一个重言式。lists由于该约束，其中的每一行都必须通过该过滤器。

如果我放弃约束，过滤器将不再显示在计划中，并且估计成本会下降一点。如果我重新添加约束，计划将再次使用过滤器。一种或另一种方式的执行速度没有显着差异。

我很担心，因为我在一个更大、更复杂的查询中发现了这个过滤器，我试图从几分钟的运行时间优化下来。

为什么 Oracle 添加该过滤器，这是一个问题和/或指向另一个问题？

编辑：如果我将约束更改sort_type为没有TRUNC零件，过滤器就会消失。如果我将约束分成两个不同的约束，过滤器就会回来。

场景：我们有一个简单的选择查询

自 1 年以来，它通常在 0.12 秒内执行。但昨天午夜过后，它突然开始消耗我所有的 CPU 并需要 150 秒才能执行。我检查了 SP_who2 并没有发现死锁，除了这个消耗所有 CPU 的查询之外什么也没有。我决定重新启动服务器以消除任何参数嗅探问题或终止任何陈旧的连接。在重新启动服务器以进行未来根本原因分析之前，我进行了 SLQ 分析器跟踪 1 分钟。重启后，一切恢复正常。我很惊讶并好奇地开始查看我采用的分析器中的执行计划，并将其与 SAME 查询的当前执行计划进行比较。我发现两者都不一样。

问题之夜前的执行计划与重启后的执行计划相同。（做完美的索引寻求）

但是有问题的 Night SQL 分析器中的执行计划正在执行完整的索引扫描，这会占用所有 CPU 并需要 150 秒才能执行。

问题：

我可以说执行计划突然重新编译或查询在昨天午夜之后开始使用新的执行计划（完全扫描），在我重新启动后，它再次开始使用旧的和良好的执行计划（索引搜索）。

Q1。是什么让 SQL server 突然使用新的 EXECUTION 计划？ Q2。是什么让 SQL Server 在重新启动后使用旧的和好的执行计划？ 第三季度。当我传递参数时，任何与参数嗅探相关的东西。但从技术上讲，它不应该像参数列那样组织良好，数据分布均匀。

我有一个托管 250+ 百万个文档的 MongoDB Sharded Cluster。

文件结构如下：

所以基本上有些文件已经卸载了该字段，有些则没有。

以下是对集合的查询（这是pymongo的解释，对不起datetime.datetime s）：

这是我收集的两个相关索引：

现在的问题是，MongoDb 查询计划器似乎永远不会选择我在集合中拥有的Index1用于完全相同的目的！

我最初的印象是查询将使用一个覆盖索引，就像我构建索引的方式一样[因此，非常快]，但对我来说很奇怪，mongodb 使用的是Index2，而且一切都太慢了，有时需要 10 分钟以上，通常在150 万个文档的结果集需要 6 分钟[即匹配的 app_id 大约有 150 万个文档]。

这是查询中解释的输出，显示使用“Index1”被拒绝的计划

以下是使用无关的、未发现的 Index2的获胜计划：

• 关于为什么 mongodb 不能正确使用我的索引的任何想法？
• 是因为某些文档中可能不存在已卸载的内容吗？
• 在进行复合日期查询时对索引方向的一些解释也将不胜感激，也许原因是索引方向？(1, -1, -1, 1)

谢谢！:)

------------编辑--------------

解释的完整结果有点长，所以我把它贴在这里，它解释了 queryPlanner 对索引 (Index2) 的选择。

同样关于 shard_key，它与这里查询的内容完全不同，这就是为什么我只为这个查询定义一个单独的特定索引。（分片键是 (app_id, android_id, some_other_field_not_in_query) 上的复合索引。

我们有一个由我们的 BI 应用程序生成的查询（可能很复杂且很大）。

当我第一次运行查询时，它需要大约 8 到 9 分钟才能执行，但是当我第二次执行它时，它需要更少的时间（15 秒）。我不确定这是因为查询的复杂性还是红移花费了更多时间来准备查询执行计划。

我已经在两个不同的环境中测试了相同的查询，每当它第一次运行时大约需要 8-9 分钟的时间，而当我下次运行它时，它会在不到 10 秒的时间内返回结果集。

我怀疑红移在准备查询计划和可执行段上花费了相当多的时间。为了澄清这一点，我检查了svl_compile表，第一次执行编译字段设置为1，对于其他后续运行，它设置为0，每当SELECT子句发生任何更改时，它都会重新编译查询并花几分钟时间返回结果集。

是否可以安全地假设：由于编译查询和准备查询计划，首次运行需要更多时间，并且仅在收集元数据方面需要更多时间。？

如果是，那么有什么方法可以减少编译时间？即使基础表没有任何数据，编译也需要相同的时间？

注意：我在运行查询之前禁用了结果缓存。
将 enable_result_cache_for_session 设置为 OFF；
实例类型：dc2.large

我想检查 JOINS 的顺序在 SQL 查询中是否对运行时和效率很重要。

我正在使用 PostgreSQL，为了进行检查，我使用了来自 MYSQL ( https://downloads.mysql.com/docs/world.sql.zip ) 的示例 world db 并编写了以下两个语句：

查询1：

查询2：

查询计划一：

查询计划2：

估计的成本和行不同，最后的哈希条件不同。这是否意味着查询规划器没有对两个查询做同样的事情，还是我走错了路？

谢谢你的帮助！

我正在对一堆物化视图测试一些查询。它们都具有相同的结构，如下所示：

显然，系统为每个查询计划提供了不同的查询计划，但如果（且仅当）WHERE 子句涉及布尔列（如示例中所示），计划程序总是在完成之前对结果集进行排序。例子：

我对这种方法真的很好奇，但我仍然没有找到对此的解释。

如果我想对一列时间戳进行分组，比如registered_at按它们发生的日期，我可以使用date_trunc('day', registered_at)或registered_at::date。第一个从时间戳中删除小时和更小的单位，但仍返回时间戳，而后者将时间戳返回到日期。现在，我想知道两者是否有比另一个更好的性能。

当我查看查询计划时，理论上的成本是完全一样的，在实际执行时间中可能会有很多噪音。

有谁知道在截断或随后使用时哪种方法更快group by？