提高 Neo4j 查询性能

因此，您当前的计划有 3 个并行线程。我们现在可以忽略一个，因为它有 0db 命中。

The biggest hit you are taking is the match for (mt:MemberTopics) ... WHERE mt.member_id = id. I'm guessing member_id is a unique id, so you will want to create an index on it CREATE INDEX ON :MemberTopics(member_id). That will allow Cypher to do an index lookup instead of a node scan, which will reduce the DB hits from ~30mill to ~1 (Also, in some cases, in-lining property matches is faster for more complex queries. So (mt:MemberTopics {member_id:id}) is better. It explicitly makes clear that this condition must always be true while matching, and will reinforce to use the index lookup)

The second biggest hit is the point-distance check. Right now, this is being done independently, because the node scan takes so long. Once you make the changes for MemberTopic, The planner should switch to finding all connected Venues, and then only doing the distance check on thous, so that should become cheaper as well.

Also, it looks like mt and gt are linked by a topic, and you are using a topic id to align them. If t and t1 are suppose to be the same Topic node, you could just use t for both nodes to enforce that, and then you don't need to do the id check to link mt and gt. If t and t1 are not the same node, the use of a foriegn key in your node's properties is a sign that you should have a relationship between the two nodes, and just travel along that edge (Relationships can have properties too, but the context looks a lot like t and t1 are suppose to be the same node. You can also enforce this by saying WHERE t = t1, but at that point, you should just use t for both nodes)

最后，根据查询返回的行数，您可能希望使用 LIMIT 和 SKIP 对结果进行分页。这看起来像是发送给用户的信息，我怀疑他们是否需要完整的转储。所以只返回最上面的结果，如果用户想看更多，只处理剩下的。（当结果接近一公吨时很有用）由于到目前为止您只有 21 个结果，因此现在这不会成为问题，但请记住，因为您需要扩展到 100,000 多个结果。