是的，你可以这样做，但是你需要在你的节点上有一个itemID或类似的，来为它们提供一个排序，否则你就不能计算运行总数。下面是它的工作方式：

MATCH (f:F) 
WITH f 
OPTIONAL MATCH (g:F) 
WHERE g.itemID<f.itemID 
RETURN f.itemID, f.shares, sum(g.shares) + f.shares 
ORDER BY f.itemID ASC;

在这里，我假设每个节点上都有一个itemID。这是必要的，因为如果你不知道哪些节点比其他节点早，或者比其他节点少，你就不能计算运行总数。但是如果你有一个像itemID这样的字段，那么你就可以对所有itemID小于你正在查看的项目进行额外的可选匹配，然后你把这些份额加起来。这就提供了一个准确的运行总数。
这不是一个非常有效的查询，因为你需要求和并不断地再求和。第一个和什么都不算，第二个和1，第三个和2（第二次和1），第四个和3（第三次和1，第二次和1），所以有很多额外的工作要做。
我们在这里所做的是一个没有可变变量值的技巧。如果我需要做这个查询，我通常会在java/javascript/python/whatever中做。我可能只是得到shares值，然后在cypher之外自己计算运行总数。

Mark Needham在这里用不同的方法回答了这个问题：

WITH [100, 100, 100, 200, 300, 500] AS allShares
UNWIND RANGE(0, LENGTH(allShares)-1) AS idx
RETURN allShares[idx],
REDUCE(acc = 0,
       value in (allShares[idx] + allShares[..idx]) |
       acc + value) AS cumulative

- ==> +-----------------------------+
- ==> | allShares[idx] | cumulative |
- ==> +-----------------------------+
- ==> | 100 | 100 |
- ==> | 100 | 200 |
- ==> | 100 | 300 |
- ==> | 200 | 500 |
- ==> | 300 | 800 |
- ==> | 500 | 1300 |
- ==> +-----------------------------+
- ==> 6 rows

我还没有在大型数据集上测试过它的性能，但乍一看，它似乎比公认的答案要快得多。

试试这个：

MATCH (n:Item)
RETURN sum(n.shares) as sum, collect(n.shares) as shares