Neo4j 4.3.2企业版大规模图数据查询性能异常问题咨询

耗时是否属于正常范围 #

• 单标签计数查询match (a:itemA) return count(a)、match (b:itemB) return count(b)耗时1ms属于正常水平，这类查询不需要扫库，Neo4j会直接返回标签计数的元数据统计值。
• 其余关联类查询耗时明显超出同规模数据的合理性能区间：同配置下700万关系量级的简单关联计数查询合理耗时应为百毫秒级，多关系关联、分组聚合查询合理耗时也应控制在3秒以内，你实测的耗时存在数倍到数十倍的性能损耗。

性能异常的可能原因 #

• 无效索引占用资源，无可用查询加速索引 #

你为itemA的prop1属性创建的索引完全无效：该属性仅3种取值，基数极低，Cypher查询优化器不会选择用这类低基数索引做查询加速，创建后仅会占用额外存储和写入性能，不会对现有查询产生任何正向收益。且所有关联查询均未配置匹配的索引/约束，所有查询均为全量节点扫描+全量关系遍历，没有任何加速手段。

• 查询计划路径选择错误 #

你给出的关联查询最优遍历路径应为「从itemA出发遍历关联关系」：每个itemA仅关联1个itemB、1个itemC，700万次遍历即可完成计数。若查询优化器错误选择从itemB/itemC出发遍历关系，会产生大量的重复节点匹配操作，性能会出现数量级下降。你可以通过EXPLAIN关键字查看查询计划的起始节点标签和遍历顺序，确认是否存在路径选择错误。

• 聚合阶段产生大量随机IO #

带a.prop1分组的查询需要逐个读取所有匹配到的itemA节点的prop1属性做聚合计算，若itemA的属性数据未完全加载到Neo4j的页缓存中，会产生大量随机磁盘IO，直接导致查询耗时成倍增长。

• 双关系查询存在冗余计算 #

双关系匹配的查询match (a:itemA)-[r:a_b]->(b:itemB), (a)-[r2:a_c]->(c:itemC) return count(a)的原生执行逻辑会先生成两个关系匹配的笛卡尔积再做去重计数，额外产生了大量无效计算，该场景下完全可以通过先统计同时存在两类关系的itemAID的方式做优化，原生执行逻辑的冗余操作会放大性能损耗。

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