我不知道为什么会出现内存不足的错误，但是看起来返回的数据溢出了V8堆的大小。另一种可能性是有什么东西导致引擎丢失/忽略索引，导致引擎在计算someIndexedSparseFiler属性之前加载每个文档。
评估数百万个文档（或大量大型文档）不仅会消耗大量磁盘/内存I/O，而且还可能需要大量RAM。尝试使用explain特性返回查询分析-它应该会告诉您哪里出了问题。
为了进行比较，我的查询...

FOR u IN myCollection
    FILTER u.someIndexedSparseFiler != null
    RETURN u._id

...当我单击“解释”时，返回以下内容：

Query String (82 chars, cacheable: true):
 FOR u IN myCollection
     FILTER u.someIndexedSparseFiler != null
     RETURN u._id

Execution plan:
 Id   NodeType          Est.   Comment
  1   SingletonNode        1   * ROOT
  7   IndexNode            5     - FOR u IN myCollection   /* persistent index scan, projections: `_id` */    
  5   CalculationNode      5       - LET #3 = u.`_id`   /* attribute expression */   /* collections used: u : myCollection */
  6   ReturnNode           5       - RETURN #3

Indexes used:
 By   Name                      Type         Collection     Unique   Sparse   Selectivity   Fields                         Ranges
  7   idx_1667363882689101824   persistent   myCollection   false    true        100.00 %   [ `someIndexedSparseFiler` ]   *

Optimization rules applied:
 Id   RuleName
  1   move-calculations-up
  2   move-filters-up
  3   move-calculations-up-2
  4   move-filters-up-2
  5   use-indexes
  6   remove-filter-covered-by-index
  7   remove-unnecessary-calculations-2
  8   reduce-extraction-to-projection

请注意，它在Indexes used:下列出了我的稀疏索引。另外，尝试将!=更改为==，您将看到现在它忽略了该索引！这是因为优化程序知道稀疏索引永远不会有null值，所以它会跳过它。
如果您不熟悉“explain”功能，那么它在优化查询和创建索引时是非常有用的（实际上是必不可少的）。在这种情况下，索引应仅具有一个属性，否则“选择性”商可能太低，引擎将忽略它。