ArangoDB NOT LIKE场景下集合FILTER快于ArangoSearch视图查询

• 两类查询的底层执行逻辑完全不同，你测试的场景刚好是ArangoSearch的天生劣势场景：
  原生集合执行FILTER t.imdb_id != 'tt9811300'时，直接走集合的原生存储遍历，只需要对每个文档做一次简单的等值判断排除单条匹配数据，几乎没有额外开销，你测到的5.6ms就是全表遍历的基线性能。
  ArangoSearch底层是倒排索引结构，所有性能优化都围绕「快速定位符合正向匹配条件的文档」设计：做等值、文本匹配、范围类正向查询时，可以直接从倒排链里捞出匹配的文档ID，性能远高于原生遍历；但遇到!=、NOT LIKE这类否定条件时，倒排索引无法直接定位结果，必须遍历索引中的全量文档逐个做条件排除，本身就比原生遍历多了一层索引读取、词条校验的开销。
• 你的查询本身会返回集合中99.9%以上的数据（仅排除1条imdb_id匹配的文档），属于接近全表返回的场景，这种场景下倒排索引的筛选收益完全覆盖不了索引层的额外开销，性能低于原生FILTER是符合预期的，不是配置错误。
• 当前的视图配置进一步放大了性能损耗：
  • 开了includeAllFields: true会给集合所有字段都建倒排索引，索引体积大，全量遍历校验时扫描的元数据更多；
  • storedValues配置为空，意味着SEARCH阶段匹配到文档ID后，必须回源到原titles集合拉取完整文档内容，多了一次跨引擎IO开销。

• 场景选型优先：纯否定条件、结果集占总数据量超过30%的全表类查询，直接用原生集合FILTER即可，不需要强行走ArangoSearch视图，这类场景原生遍历本身就是最优解。ArangoSearch更适合搭配至少一个正向筛选条件、结果集过滤比例高的查询（比如文本检索、多条件组合过滤），才能发挥倒排索引的性能优势。
• 调整视图配置减少不必要开销：
  • 关闭includeAllFields: true，只在links.titles.fields中显式声明需要做SEARCH过滤的字段，减小倒排索引整体体积，降低全量遍历的扫描成本：

    "links": {
      "titles": {
        "analyzers": ["identity"],
        "fields": {
          "imdb_id": {}
        },
        "includeAllFields": false,
        "storeValues": "none",
        "trackListPositions": false
      }
    }
    

  • 把查询中需要返回、需要做过滤判断的字段加入storedValues配置，让视图直接存储字段值，避免查询时回表拉取原集合数据，通常能降低30%以上的额外开销：

    "storedValues": ["imdb_id"]
    

  • 如果有高频的等值、排序查询场景，可以把对应字段加入primarySort配置，利用视图的排序缓存进一步加速条件判断。

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