ArangoDB：如何优化大集合中子查询的FILTER语句

问题背景 #

基于IMDB数据设计的数据模型包含3个集合：

• 文档集合Titles：存储影片信息
• 文档集合Persons：存储人物信息
• 边集合core_edge_values_links：关联影片与人物，通过attribute字段标识角色（如导演、演员）

需求是查询所有关联导演的Titles，现有两种查询方式均存在性能问题：

1. 遍历查询：耗时约2.5秒，开启fullCount后接近2分钟，未利用_from+attribute组合索引
2. Join查询：虽利用索引，但耗时仍约2.5秒，根源是全量扫描100万条Titles数据

原始查询与性能分析 #

遍历查询 #

FOR r IN titles
    LET rlinkVal =  FIRST( 
        FOR rv, re IN 1 OUTBOUND r._id
            core_edge_values_links
            FILTER re.attribute == 'directors'
         RETURN re
     ) 
     FILTER rlinkVal != null
LIMIT 0, 20
RETURN r

性能分析摘要：

• 执行计划显示对titles做全集合扫描（304000条）
• 遍历仅用到core_edge_values_links的_from边索引，未利用attribute字段的组合索引
• 总执行时间约2.41秒

Join查询 #

FOR r IN titles
    LET rlinkVal =  FIRST( 
        FOR e IN core_edge_values_links
            FILTER e._from == r._id AND e.attribute == 'directors'
            RETURN true
     ) 
     FILTER rlinkVal != null
     LIMIT 0, 20
     RETURN r

性能分析摘要：

• 同样对titles做全集合扫描
• 虽用到core_edge_values_links的[_from, attribute]组合索引，但循环查询每条影片对应的边，总执行时间约2.65秒

优化方案 #

方案1：反转查询方向（从边集合入手） #

核心思路：不再全量扫描Titles，而是先筛选出所有attribute='directors'的边，再关联对应的影片，利用组合索引快速定位目标边，避免全表扫描。

优化后查询：

FOR e IN core_edge_values_links
    FILTER e.attribute == 'directors'
    LET title = DOCUMENT(e._from)
    LIMIT 0, 20
    RETURN title

优势：

• 直接通过[_from, attribute]组合索引筛选目标边，无需扫描全部Titles
• 若需要获取全量结果（带fullCount），该方式性能远优于原查询，仅处理60万条目标边而非100万条影片

方案2：给Titles添加标记字段（预计算） #

如果需要频繁查询带导演的影片，可在Titles集合中新增has_director布尔字段，数据写入或更新时同步维护：

• 当影片关联导演边时，设置has_director=true
• 当导演边被删除时，检查是否还有其他导演边，若无则设置has_director=false

之后查询可直接过滤：

FOR r IN titles
    FILTER r.has_director == true
    LIMIT 0, 20
    RETURN r

优势：

• 查询时直接利用has_director字段的索引，性能最优
• 适合高频查询场景，代价是写入时增加维护逻辑

方案3：优化图遍历写法 #

调整遍历查询逻辑，让优化器更好地利用组合索引：

FOR r IN titles
    FOR re IN 1 OUTBOUND r core_edge_values_links
        FILTER re.attribute == 'directors'
        LIMIT 1
        RETURN r

说明：

• 移除子查询和FIRST()，直接在遍历后过滤并限制1条结果，优化器可能更高效地利用索引
• 但本质仍会扫描Titles集合，性能提升有限，适合无法反转查询方向的场景

验证建议 #

• 执行优化后的查询时，查看执行计划确认是否使用了预期的索引
• 对于fullCount需求，使用方案1时可添加OPTIONS {fullCount: true}，性能远优于原查询

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