我正在Neo4j中对用户授权/数据保护方案进行原型设计，我遇到了一个与我的查询有关的奇怪问题。对于背景，概念是如果用户具有正确的访问标识符，则尝试从a到达的用户可以成为。因此，我们的边缘是具有访问标识符的类型。我正在通过创建大量节点来测试这个方案，并通过不同的访问来连接它们。也就是说，我有很多套：
(a)-[:ACCESS_A]->(b)
具有不同的访问权限。我用以下方法查询它们：
{some query} with a match (a)-[:ACCESS_A|:ACCESS_B|<...>|:ACCESS_Z]->(b) return b
其中边缘匹配中列表的大小随用户的访问次数而增长。
这一切都很有效，直到列表获得201次访问。此时，配置文件显示db命中和时间。在200种关系类型中，配置文件显示1051 db命中，但201种关系类型显示31801.这是另外一种类型的30倍增加！所用时间以类似方式增加。从199到200只上升约50次点击，这是由于节点数量增加所致。
经过更多的工作，看起来圆形的200号码比问题更像红色鲱鱼。以前，我的关系类型是4个字符。当我将它们改为9个字符时（在“EDGE_”之前，作为测试），问题开始发生在50种类型--50有36次访问，而51有291 - 较小的跳跃，但与之前相同的增加相比显着测试
似乎关系名称与查询失败的位置存在某种关系，但我仍在调查。
我测试过的事情并没有引起人们的兴趣：
答案 0 :(得分：1)
据我所知，您不应该只遇到200种关系类型的性能问题。
在3.0版之前，关系类型的数量上限为64k。版本3.0已删除该限制。
答案 1 :(得分：0)
我能够找到解决问题的方法。似乎要求Neo4j提供比存在更多不同的关系类型会导致问题。当这些类型都存在时，我能够使用超过200个。因此，解决方案是确保您不要求图表中没有任何类型。