我正在使用LOAD CSV命令合并大批约500,000个关系：
LOAD CSV WITH HEADERS FROM 'http://file.csv'
MATCH (a:Label {uid: csv.uid1}),(b:Otherlabel {uid: csv.uid2})
MERGE (a)-[:TYPE {key1: csv.key1}]->(b)
uid个属性都有UNIQUE个约束。
CSV文件如下所示：
uid1,uid2,key1
123,abc,some_value
456,def,some_value
当每边有许多不同的节点时，通常非常快（<1分钟）。
但是当我加载一个a节点连接到许多不同b节点的批处理时，性能会急剧下降。 uid1始终相同，但架构约束仍然存在。 ~30,000个关系需要~8分钟才能加载。
我在这里遗漏了什么吗？什么可以解释MERGE多对多＆＃39;中的巨大性能差异？人际关系与一对多＆＃39;？
答案 0 :(得分：0)
正如我在该问题的评论中所提到的，我使用uid1和uid2的唯一随机值创建的~300,000行CSV文件验证了此行为。 @MartinPreusse然后提到，如果您将查询更改为使用CREATE而不是MERGE，则查询速度很快。这一观察让我意识到发生了什么。
减速是由于需要扫描＆＃39; a＆＃39;的关系列表所致。每次执行MERGE时节点。执行CREATE时，将添加关系而不先测试以查看关系是否已存在。当关系列表保持简短（第一种情况）时，扫描关系列表几乎没有影响。当关系列表增长很长时（第二种情况），重复扫描不断增长的列表主导着这个过程。在我的测试中，我使用MERGE子句将所有300,000个节点链接到单个节点，并且花费了数小时。
如果您不必担心创建重复关系，则可以毫无顾虑地使用CREATE。即使重复是一个问题，使用CREATE然后制作一个将删除重复项的查询可能会更快。