Neo4j-3个不同查询的并集

我对一个组合查询有一个问题，它有三个部分

结交直接朋友 交朋友的朋友 找其他人-只需填满空间以限制 因此，它应该总是返回有限的用户，由直接的朋友、朋友的朋友和其他人订购。前两个部分速度很快，这里没有问题，但最后一个部分速度很慢，而且随着db的增长速度越来越慢。Person.number和Person.createdAt上有索引

有人知道如何改进或重写此查询以提高性能吗

MATCH (me:Person { number: $number })-[r:KNOWS]-(contact:Person { registered: "true" }) WHERE contact.number <> $number AND (r.state = "contact" OR r.state = "declined")
    MATCH (contact)-[:HAS_AVATAR]-(avatar:Avatar { primary: true })
    WITH contact, avatar
    RETURN contact AS friend, avatar, contact.createdAt AS rank
    ORDER BY contact.createdAt DESC
  UNION
    MATCH (me:Person { number: $number })-[:KNOWS]-(friend)-[:KNOWS { state: "accepted" }]-(friend_of_friend:Person { registered: "true" }) WHERE NOT friend.username = 'default' AND NOT (me)-[:KNOWS]-(friend_of_friend)
    MATCH (friend_of_friend)-[:HAS_AVATAR]-(avatar:Avatar { primary: true })
    OPTIONAL MATCH (friend_of_friend)-[rel:KNOWS]-(friend)
    RETURN friend_of_friend AS friend, avatar, COUNT(rel) AS rank
    ORDER BY rank DESC
  UNION
    MATCH (me:Person { number: $number })
    MATCH (others:Person { registered: "true" }) WHERE others.number <> $number AND NOT (me)-[:KNOWS]-(others) AND NOT (me)-[:KNOWS]-()-[:KNOWS { state: "accepted" }]-(others:Person { registered: "true" })
    MATCH (others)-[:HAS_AVATAR]->(avatar:Avatar { primary: true })
    OPTIONAL MATCH (others)-[rel:KNOWS { state: "accepted" }]-()
    WITH others, rel, avatar
    RETURN others AS friend, avatar, COUNT(rel) AS rank
    ORDER BY others.createdAt DESC
  SKIP $skip
  LIMIT $limit

以下是一些简介：

最终的解决方案是将整个查询分解为三个并分别调用它们，在我们的例子中，99%的查询不会到达第三个查询，前两个查询速度非常快。而且看起来，即使它达到第三阶段，它仍然很快，所以也许工会是最慢的整个事情

const contacts = await this.neo4j.readQuery(`...
if (contacts.records.length < limit){
  const friendOfFriend = await this.neo4j.readQuery(`...
  if (contacts.records.length + friendOfFriend.records.length < limit){
    const others = await this.neo4j.readQuery(`...

merge all results

---

在限制之前的第三个查询中，您做了大量工作。您可能希望尽快将订单和限额上调

在单个匹配模式中预匹配朋友和朋友的朋友会更有效，我们可以使用*0..1作为与潜在下一个节点的可选关系

还有一点风格建议，我发现为列表/集合保留复数形式是个好主意，否则使用单数形式，因为每行只有一个节点

请在第三部分中尝试以下内容：

  MATCH (me:Person { number: $number })
  OPTIONAL MATCH (me)-[:KNOWS]-()-[:KNOWS*0..1 { state: "accepted" }]-(other:Person {registered:"true"})
  WITH collect(DISTINCT other) as excluded
  MATCH (other:Person { registered: "true" }) WHERE other.createdAt < dateTime() AND other.number <> $number AND NOT other IN excluded
  WITH other
  ORDER BY other.createdAt DESC
  SKIP $skip
  LIMIT $limit
  MATCH (other)-[:HAS_AVATAR]->(avatar:Avatar { primary: true })
  WITH other, avatar, size((other)-[:KNOWS { state: "accepted" }]-()) AS rank
  RETURN other AS friend, avatar, rank

---

如果我们知道createdAt的类型，那么我们可以添加一个修改，该修改可能会触发索引支持的排序，从而改善这一点。

您能在此查询上运行配置文件吗，使用结果窗格右下角的双向下箭头展开结果计划按钮的所有元素，并将图像添加到您的问题中？createdAt是datetime，这有点提高了性能，但仍然非常缓慢。我只是对查询添加了一个更改，我认为应该使用索引支持的排序。试一试，看看你能不能得到一个关于这个的简介。结果似乎非常相似，又增加了一个简介。还有一个问题，我如何才能从那些工会那里得到50个结果，现在我可以看到更多的结果。对工会有什么限制吗？因为限制似乎只适用于最后一个查询。谢谢您的提示，毕竟我将此查询分解为三个，分别调用它们，并且只有在前一个结果计数低于限制50时才在必要时调用下一个查询。令人惊讶的是，从统计数据来看，99%的用户似乎不会达到第三阶段，如果是这样，速度会非常快。所以，也许是工会拖慢了整个进程。