对比两种Neo4j指定节点关系类型计数查询的效率

针对统计指定起始节点各关系类型数量的需求，先明确两种方案的典型实现，再分析大关系量场景下的性能差异：

方案1：纯Cypher查询 #

通过MATCH遍历节点所有关系，结合type()和count()分组统计：

MATCH (n {id: $startNodeId})-[r]->()  // 统计入关系则替换为<-[r]-
RETURN type(r) AS relationshipType, count(r) AS count

性能特点 #

• 核心逻辑是遍历所有目标关系 + 分组聚合，关系数量越多，遍历和聚合的开销线性增长。
• 依赖Neo4j原生的关系遍历优化，存储层面是面向关系的结构，遍历效率本身不错，但当单节点关系量达到十万/百万级时，全量遍历的耗时会显著上升。

方案2：APOC结合查询 #

利用APOC工具包的关系类型枚举和度数统计函数，直接读取节点的度数缓存：

MATCH (n {id: $startNodeId})
CALL apoc.node.relationship.types(n) YIELD relationshipType
WITH n, relationshipType
WHERE relationshipType IS NOT NULL  // 过滤空类型行
RETURN relationshipType, apoc.node.degree.out(n, relationshipType) AS count  // 统计入关系替换为in

性能特点 #

• 核心逻辑是读取节点元数据中的度数缓存：Neo4j会为每个节点维护各关系类型的入/出度数统计，apoc.node.degree.*()直接读取该缓存，无需遍历实际关系。
• 无论单类型关系量多大，每个类型的度数查询都是O(1)操作。当节点关系总量大（尤其是多类型、单类型关系量极高）时，这个方案的性能优势极其明显——比如节点有10种各含10万条的关系，APOC方案仅需10次缓存读取，而纯Cypher需要遍历100万条关系再聚合。

大关系量场景结论 #

当目标节点的关系数量较多时，APOC方案的效率远高于纯Cypher方案。纯Cypher的全关系遍历+聚合在大数量级下会产生显著的IO和计算开销，而APOC方案利用了数据库内置的度数缓存，完全避免了遍历实际关系的成本。

只有当节点关系总量极少时，两者性能差异可忽略，此时纯Cypher可能因少了APOC过程调用的微小开销略占优，但这种场景下性能差异无实际意义。

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