使用非唯一非稀疏哈希索引时查询字段过滤失效问题

首先，你遇到的这个现象核心原因在于ArangoDB查询优化器对部分覆盖索引的处理逻辑，结合数组字段的索引特性来拆解：

1. 仅a,b[*]索引时的问题根源 #

你创建的第一个哈希索引包含a（普通字段）和b[*]（数组字段，[*]表示索引数组的每个元素），当执行子查询的过滤条件rr.a == true && r.id IN rr.b && r.id IN rr.c时：

• 查询优化器会优先选择这个索引来快速定位满足rr.a == true且r.id IN rr.b的文档，因为这两个条件完全匹配索引覆盖的字段；
• 但由于索引里没有c[*]的信息，优化器需要从磁盘/内存中读取这些匹配文档的原始数据，再检查r.id IN rr.c的条件；
• 这里出现的“仿佛c条件被忽略”的问题，本质上是优化器在某些场景下（比如索引返回的结果集过大、统计信息不准确），错误地跳过了对c字段的过滤，或是回表检查的步骤没有正确生效。

2. 添加c[*]到索引后的修复逻辑 #

当你创建包含a,b[*],c[*]的哈希索引后：

• 这个索引完全覆盖了所有三个过滤条件：rr.a == true（匹配a字段）、r.id IN rr.b（匹配b[*]的索引条目）、r.id IN rr.c（匹配c[*]的索引条目）；
• 查询优化器可以直接通过索引完成所有条件的筛选，不需要回表读取原始数据，因此过滤逻辑完全生效，结果符合预期。

3. 额外的验证与建议 #

• 你可以通过EXPLAIN命令查看两种索引下的执行计划细节，对比差异：

  EXPLAIN FOR r IN coll RETURN COUNT( FOR rr IN coll2 FILTER rr.a == true && r.id IN rr.b && r.id IN rr.c RETURN null )
  

  重点看两个索引下的Filter节点是否包含r.id IN rr.c的条件，以及是否存在IndexRangeScan之后的Lookup（回表）操作。
• 如果不想创建包含三个字段的索引，也可以尝试强制优化器不使用第一个索引（通过注释排除），验证是否是优化器的索引选择逻辑导致的问题：

  FOR r IN coll RETURN COUNT( 
    FOR rr IN coll2 /*+ optimizer({indexes: [{collection: 'coll2', index: '你的第一个索引名称'}]}) */
    FILTER rr.a == true && r.id IN rr.b && r.id IN rr.c 
    RETURN null 
  )
  

内容的提问来源于stack exchange，提问作者sowee15