Gremlin单查询实现双顶点upsert时为何第二个操作触发全图遍历

核心根因 #

踩这个坑本质是对Gremlin的遍历上下文传递规则没摸透：

• Gremlin遍历流的上下文是一路向下传递的，不会在碰到V()步骤时自动重置到全局图根重新查询。
• 现有代码在第一个顶点upsert完成后，遍历流中还留存着id=1的Company顶点的上下文引用，这时候直接接.V('2')，引擎根本不会走"通过id匹配全局顶点索引"的快速路径，反而会从当前持有的Company顶点出发，遍历所有可达顶点来匹配id=2的条件。
• 遇到未做过非根上下文V()优化的图引擎时，这个流程会直接退化为全图遍历，完全偏离两个顶点独立upsert的预期。

可正常运行的修正写法 #

要保证每一段独立的顶点upsert逻辑，都是从全局图根节点发起V()查询，避开上下文绑定问题，修正后的查询如下：

g
  .inject()
  // 第一个顶点的upsert逻辑单独隔离
  .sideEffect(
    V('1')
      .fold()
      .coalesce(
        unfold(),
        addV('Company').property('id', '1').property('pk', '1')
      )
  )
  .inject()
  // 第二个顶点的upsert逻辑完全独立，不受前序结果影响
  .sideEffect(
    V('2')
      .fold()
      .coalesce(
        unfold(),
        addV('Person').property('id', '2').property('pk', '2')
      )
  )
  .barrier()

调整逻辑说明 #

• 用sideEffect把两段upsert逻辑做隔离，每段内部的V()调用都是从全局根发起的，能直接命中顶点id的原生索引，从根源上避免全图扫描。
• 砍掉原来直接把两个V()查询串在同一条遍历流里的写法，避免第二个查询被第一个顶点的上下文绑定。
• 最后加barrier()步骤确保两段upsert的写操作都执行完成后再返回结果，避开部分图引擎延迟执行带来的逻辑偏差。

常见认知误区 #

很多开发者写Gremlin的时候会默认V()是全局通用的查询入口，但实际上只有从遍历起点（也就是g之后的第一步）发起的V()才会走全局索引的快速路径。只要V()前面存在其他步骤返回的元素，引擎就会把V()的过滤条件限定在当前遍历路径的可达元素范围内，根本触发不了全局索引查询，严重时就会退化为全图遍历。

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