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

在移动到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 }

集合事件在日期中具有skiplist索引，在所有者中具有哈希索引

---

没有SORT E.date desc或SORT EventLast[0]-1ms，2.8-beta版中的查询优化器为内部子查询选择了日期上的skiplist索引。此索引允许删除SORT子句，但内部查询仍需要按相反顺序扫描整个索引，直到第一个筛选器匹配为止。它能做到的次数与亲自提交文件的次数一样多

取而代之的是，2.7优化器在owner上选择散列索引，并使用post索引排序。在这种情况下，如果每个索引查找的匹配数非常小，那么这可能会更好，但是如果过滤器非常非选择性，那么这将是不好的

---

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

您是否也可以共享Person和Event中的文档的大致数量以及报告的哈希索引选择性？这将与2.7进行更好的比较。谢谢Person-1000 Event-10000Event.owner-hash index selectivity 14.4%P.S.我从未见过在ArangoDb上有100%的使用率，在没有索引的更复杂查询中也有。最长为0.5-0.9秒，但此查询会使数据库在8-10扇区上变成僵尸高CPU负载是由于该查询执行1000个外循环*10000个内循环文档查找和筛选操作，总计10000000。这是CPU要做的相当多的工作。在这种情况下，使用正确的索引散列，操作的数量将下降到大约1000个外循环*1/0.14个内循环加上排序。这将导致总共不到30000个内部ops，这要快几个数量级。正如我在回答中提到的，已经提交了一个修复程序，并将包含在beta2之后的版本中。