任务：更新许多边缘属性的最快方法。出于性能原因，我忽略了图形方法，并直接使用集合进行过滤。
ArangoDB 2.8b3
查询[优惠 - 边缘集合]：
FOR O In Offer
FILTER O._from == @from and O._to == @to and O.expired > DATE_TIMESTAMP(@newoffertime)
UPDATE O WITH { expired: @newoffertime } IN Offer
RETURN { _key: OLD._key, prices_hash: OLD.prices_hash }
我在_to，_ from和范围索引上有系统索引已过期
查询解释show
7 edge Offer false false 49.51 % [ `_from`, `_to` ] O.`_to` == "Product/1023058135528"
系统索引仅用于过滤部分记录（_to），而不是用于两者（_from，_to），'expired'索引也未使用。请解释一下这种行为的原因，如果我在规划数据模型时肯定知道的话，有可能指定用于最短路径的索引提示吗？
答案 0 :(得分：3)
对于过滤条件与查询中的逻辑AND结合使用，ArangoDB的查询优化器将选择一个索引。这就是为什么它没有同时选择边缘索引和跳过列表索引。
它将在expired上的跳转列表索引和[ "_from", "_to" ]上的边缘索引之间进行选择，并选择确定较低成本的那个，这是通过索引选择性估计来衡量的。正如解释输出所示，它似乎已经在_to上选择了边缘索引。
边缘索引内部由两个单独的哈希索引组成，一个位于_from属性，另一个位于_to属性，因此可以通过_from和{_to快速访问{1}}属性。但是，它在<{1}}上的不组合索引，因此它不支持同时请求[ "_from", "_to" ]和_from的查询。它必须选择一个内部哈希索引，并且似乎在该查询中选择_to上的那个。该决定再次基于平均指数选择性。
无法向优化器提供任何索引使用提示 - 除此之外，它无法同时为此特定查询使用两个索引。
查看解释输出中的选择性估计，似乎边缘索引不是非常有选择性，这意味着会有许多具有相同_to值的边。由于优化器也应该考虑_to上的索引，我会假设索引的选择性更低，并且每个索引只会有助于跳过最多50％的边缘，这不是非常。如果情况确实如此，那么查询仍将检索（并过滤后）大量文档，解释潜在的缓慢。
目前，属性_from和_from在边集合的始终存在的边缘索引中自动编入索引，并且它们不能用于其他用户定义的索引中。
这是我们希望在将来的版本中添加的功能，因为_to和_from可以访问用户定义的索引，可以在{{1}上创建组合（排序）索引这可能比隔离的三个单属性索引中的任何一个更具选择性。