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和范围索引的系统索引已过期
查询解释显示
7 edge Offer false false 49.51 % [ `_from`, `_to` ] O.`_to` == "Product/1023058135528"
系统索引仅用于过滤部分记录(_to),而不是用于(_from,_to),’过期’索引也不使用.请解释一下这种行为的原因,如果我在规划数据模型时肯定知道的话,有可能指定用于最短路径的索引提示吗？
对于在查询中结合逻辑AND的过滤条件,ArangoDB的查询优化器将选择单个索引.这就是为什么它没有同时选择边缘索引和跳转列表索引的原因.它将在过期的跳过列表索引和[“_ from”,“_ to”]上的边缘索引之间进行选择,并将选择确定较低成本的那个,这是通过索引选择性估计来衡量的.正如解释输出所示,它似乎已经选择_to上的边缘索引.
边缘索引内部由两个单独的哈希索引组成,一个在_from属性上,一个在_to属性上,因此它允许通过_from和_to属性快速访问.但是,它不是[“_ from”,“_ to”]的组合索引,因此它不支持同时请求_from和_to的查询.它必须选择一个内部哈希索引,并且似乎在该查询中选择_to上的那个.该决定再次基于平均指数选择性.
无法向优化器提供任何索引使用提示 – 除此之外,它无法同时为此特定查询使用两个索引.
看看解释输出中的选择性估计,似乎边缘索引不是很有选择性,这意味着会有很多边具有相同的_to值.由于优化器也应该考虑_from上的索引,我会假设索引的选择性更低,并且这些索引中的每一个只能帮助跳过最多50％的边缘,这不是很多.如果确实如此,那么查询仍将检索(并过滤)大量文档,解释潜在的缓慢.
目前,属性_from和_to在边集合的始终存在的边缘索引中自动编入索引,并且它们不能用于其他用户定义的索引中.这是我们希望在将来的版本中添加的功能,因为_from和_to可以访问用户定义的索引,可以在[“_ from”,“_ to”,“expired”上创建组合(排序)索引这可能比隔离的三个单属性索引中的任何一个更具选择性.