为何Gremlin的Until/Repeat查询性能远低于直接边遍历？

场景回顾 #

先看用于构建测试数据的Gremlin查询：

g.addV('root').as('root')
.addV('person').as('person')
.addE('contains').from('root').to('person')

测试场景非常简单：仅包含一个root顶点，通过contains边连接一个person顶点。

直接边遍历查询（高性能） #

查询语句及性能数据：

profile
g.V('f4c17843-394d-a720-5525-bb7bedced833').as('person')
.inE('contains').outV().hasLabel('root').as('root')

Until/Repeat循环查询（低性能） #

查询语句及性能数据：

profile
g.V('f4c17843-394d-a720-5525-bb7bedced833').as('person')
.until(hasLabel('root')).repeat(inE('contains').outV()).as('root')

性能差异的核心原因 #

1. 执行模型本质不同 #

直接遍历是线性单步路径查询：

• 从指定person顶点出发，仅需执行inE('contains').outV一步即可到达root顶点，再做标签校验。整个流程是固定的单步操作，图数据库可以直接做路径合并优化，甚至通过索引直接定位目标顶点，几乎没有额外控制开销。

until(repeat())是循环迭代执行模型：

• 它是为未知深度的遍历场景设计的框架，哪怕只需要迭代一次，也必须完成「初始化循环状态 → 执行遍历步骤 → 检查终止条件 → 销毁循环上下文」的完整流程。这些循环控制逻辑会带来固定的额外开销，在小数据量场景下占比极高。

2. 优化空间的差异 #

直接遍历逻辑简单，数据库可做深度优化：

• 可以把inE('contains').outV().hasLabel('root')合并为一个逻辑步骤，直接通过边的关联关系定位到符合标签的顶点，避免多步拆分的执行成本。

until(repeat())的灵活性限制了优化：

• 数据库无法提前预判循环迭代次数，必须保留完整的循环控制逻辑，无法像单步查询那样做合并优化；同时循环过程中需要维护迭代状态（当前遍历顶点、迭代次数等），进一步增加了运行时开销。

3. 固定运行时开销的放大 #

repeat遍历会引入单步查询没有的额外操作：

• 循环计数器维护、终止条件的每次检查、迭代上下文的保存与恢复，这些操作的固定开销在仅需一次迭代的场景下，会被无限放大，最终导致性能差距达到数十倍。

总结 #

until/repeat的设计目标是处理未知深度的遍历场景（比如需要遍历N层直到找到目标，N不确定），它的灵活性是以额外的循环控制开销为代价的。在明确仅需单步遍历的场景下，直接使用线性路径查询自然会有数量级的性能优势。

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