ArangoDB 2.8 - 按子查询结果排序 - 失败答案

【问题标题】：ArangoDB 2.8 - sort by subquery result - failureArangoDB 2.8 - 按子查询结果排序 - 失败
【发布时间】：2015-12-17 19:56:27
【问题描述】：

在迁移到 2.8 后，这个简单的查询现在冻结了服务器，CPU 使用率为 100%，大约 10 秒。在 2.7 (~30ms)

FOR P In Person
   LET EventLast = (
    FOR E In Event FILTER E.owner == P._id SORT E.date desc LIMIT 1 RETURN E.date
   )
SORT EventLast[0]
LIMIT 40
RETURN { _id: P._id, name:P.name }

收集事件在date 中具有跳过列表索引，在owner 中具有哈希索引

没有“SORT E.date desc”或“SORT EventLast[0]” - 1ms

【问题讨论】：

您能否分享Person 和Event 中文档的大致数量以及报告的哈希索引选择性？这将允许与 2.7 进行更好的比较。谢谢！
人员 - 1000 事件 - 10000
Event.owner - 哈希索引选择性 14.4% P.S.在没有索引的更复杂查询上，我从未见过 ArangoDb 100% 的使用率。最长 0.5-0.9 秒，但此查询在 8-10 秒内将数据库变为僵尸
高 CPU 负载是由于查询执行了 1,000（外循环）*10,000（内循环）文档查找和过滤操作，总共 10,000,000。这对 CPU 来说是相当多的工作。使用正确的索引（在本例中为哈希），操作数将下降到大约 1,000（外循环）* 1 / 0.14（内循环）加上排序。这应该会导致总共少于 30,000 个内部操作，这要快几个数量级。正如我在回答中提到的，已提交修复并将包含在 beta2 之后的版本中。

标签： performance sorting arangodb

【解决方案1】：

2.8-beta 中的查询优化器为内部子查询选择了 date 上的跳过列表索引。该索引允许删除SORT 子句，但内部查询仍然需要以相反的顺序扫描整个索引，直到第一个过滤器匹配。它执行的次数与 Person 中的文档一样多。

2.7 优化器选择了owner 上的哈希索引并使用了后索引-SORT。在这种情况下，如果每次索引查找的匹配数非常少，这可能会更好，但如果过滤器非常不具选择性，那就不好了。

2.8 优化器现在将再次偏爱可能更具选择性的哈希索引用于内部查询。今天在2.8 分支中对此进行了修复，该分支将变为 beta3 或 rc（请注意，很快会有一个 beta2 尚不包含修复）。

【讨论】：