Question

当我尝试在ArangoDB中只使用一个过滤器执行内连接时，如下所示：

FOR doc1 in catalogue
FOR doc2 in RepoNodes
 FOR doc3 in RepoEdges
 FOR doc4 in RepoNodes
   FOR doc5 in RepoEdges
          FOR doc6 in RepoNodes
            FOR doc10 in catalogue
             FOR doc11 in similarities
              FOR doc12 in clearance

 FILTER doc1.trackid== "TRAAAAK128F9318786" AND doc1.trackid==doc2.mongodbsongs
AND doc3._from==doc2._id AND doc3._to ==doc4._id AND doc5._from==doc4._id and    doc6._id ==doc5._to
AND   doc10.trackid== doc6.mongodbsongs
AND doc11._from==CONCAT("Tracks/",doc6.neo4jSong)
AND doc6.redisclearance== doc12._key
         return {doc10,doc11,doc12}

我注意到索引被忽略了..我的意思是..它执行完整的集合扫描。如果我序列化相同的查询，它的工作完美。我不明白为什么.. 如果我在最后4个之前停止它好了.. 问题出在哪儿？为什么需要完整的集合扫描？

Answer 1

在后一个查询（不使用索引的查询）中，查询优化器执行一个函数，该函数将在查询中移动FOR循环。它将尝试创建所有可能的FOR循环排列，这些排列不会改变查询的含义。

在后一个查询中，优化器可以随意移动9个FOR循环中的任何一个，因为它们之间没有可能有问题的FILTER语句。在这里，优化器将开始创建新的执行计划，其中FOR循环移动。这可以创造9！（教师，即362880）不同的执行计划，但默认情况下，优化器停在192个计划，以避免组合爆炸。当达到该计划数量时，优化器将停止应用一些进一步的优化，以便限制整个优化运行时。

这就是为什么在第二个查询中 EnumerateCollectionNode 未转换为 IndexNode 的原因。优化器在此步骤之前已经停止，因为已经有很多执行计划。

在第一个查询中，优化器不能随意移动FOR循环，因为FILTER语句限制了一些移动。因此，它不会产生太多的执行计划，也不会过早地停止优化。

版本3.0.2包含此修复程序。之前的临时解决方法是将第二个查询中的一个FILTER语句拆分为多个较小的FILTER语句，并将它们移动到各自的FOR循环附近。

ArangoDB完整集合扫描和JOIN

1 个答案: