0
我有一個像節點(1) - >節點(2) - >節點(3)的樹結構。我有一個名稱作爲用於檢索節點的屬性。給定節點say節點(3),我想檢索節點(1)。在有向圖中找到樹的根
查詢嘗試:
MATCH(P:節點) - [:HAS *] - >(C:節點)WHERE c.name = 「節點3」 RETURN p LIMIT 5
但是,不能夠獲得節點1.
我有一個像節點(1) - >節點(2) - >節點(3)的樹結構。我有一個名稱作爲用於檢索節點的屬性。給定節點say節點(3),我想檢索節點(1)。在有向圖中找到樹的根
查詢嘗試:
MATCH(P:節點) - [:HAS *] - >(C:節點)WHERE c.name = 「節點3」 RETURN p LIMIT 5
但是,不能夠獲得節點1.
您的查詢不僅會返回「節點1」,但它至少應包含一個包含它的路徑。這是可能的篩選路徑只得到了一個一路穿越到根,但是:
MATCH (c:Node {name: "node 3"})<-[:HAS*0..]-(p:Node)
// The root does not have any incoming relationship
WHERE NOT (p)<-[:HAS]-()
RETURN p
注意使用0長度的,它匹配所有的情況下,包括一個在起始節點是的根。有趣的事實:即使你在Node:name上有一個索引,它也不會被使用(除非你使用的是Neo4j 3.1,它至少在3.1 Beta2之後似乎是固定的),你必須明確地指定它。
MATCH (c:Node {name: "node 3"})<-[:HAS*0..]-(p:Node)
USING INDEX c:Node(name)
WHERE NOT (p)<-[:HAS]-()
RETURN p
第一查詢使用PROFILE
(帶有一個數字id
屬性,而不是name
):
+-----------------------+----------------+------+---------+-------------------------+----------------------+
| Operator | Estimated Rows | Rows | DB Hits | Variables | Other |
+-----------------------+----------------+------+---------+-------------------------+----------------------+
| +ProduceResults | 0 | 1 | 0 | p | p |
| | +----------------+------+---------+-------------------------+----------------------+
| +AntiSemiApply | 0 | 1 | 0 | anon[23], c -- p | |
| |\ +----------------+------+---------+-------------------------+----------------------+
| | +Expand(All) | 1 | 0 | 3 | anon[58], anon[67] -- p | (p)<-[:HAS]-() |
| | | +----------------+------+---------+-------------------------+----------------------+
| | +Argument | 1 | 3 | 0 | p | |
| | +----------------+------+---------+-------------------------+----------------------+
| +Filter | 1 | 3 | 3 | anon[23], c, p | p:Node |
| | +----------------+------+---------+-------------------------+----------------------+
| +VarLengthExpand(All) | 1 | 3 | 5 | anon[23], p -- c | (c)<-[:HAS*]-(p) |
| | +----------------+------+---------+-------------------------+----------------------+
| +Filter | 1 | 1 | 3 | c | c.id == { AUTOINT0} |
| | +----------------+------+---------+-------------------------+----------------------+
| +NodeByLabelScan | 3 | 3 | 4 | c | :Node |
+-----------------------+----------------+------+---------+-------------------------+----------------------+
Total database accesses: 18
,並在第二個:
+-----------------------+----------------+------+---------+-------------------------+------------------+
| Operator | Estimated Rows | Rows | DB Hits | Variables | Other |
+-----------------------+----------------+------+---------+-------------------------+------------------+
| +ProduceResults | 0 | 1 | 0 | p | p |
| | +----------------+------+---------+-------------------------+------------------+
| +AntiSemiApply | 0 | 1 | 0 | anon[23], c -- p | |
| |\ +----------------+------+---------+-------------------------+------------------+
| | +Expand(All) | 1 | 0 | 3 | anon[81], anon[90] -- p | (p)<-[:HAS]-() |
| | | +----------------+------+---------+-------------------------+------------------+
| | +Argument | 1 | 3 | 0 | p | |
| | +----------------+------+---------+-------------------------+------------------+
| +Filter | 1 | 3 | 3 | anon[23], c, p | p:Node |
| | +----------------+------+---------+-------------------------+------------------+
| +VarLengthExpand(All) | 1 | 3 | 5 | anon[23], p -- c | (c)<-[:HAS*]-(p) |
| | +----------------+------+---------+-------------------------+------------------+
| +NodeUniqueIndexSeek | 1 | 1 | 2 | c | :Node(id) |
+-----------------------+----------------+------+---------+-------------------------+------------------+
Total database accesses: 13
抱起來,爲什麼不名稱被查詢中的索引自動使用?是否有影響Neo4j 3.0.x的錯誤? – InverseFalcon
@InverseFalcon我想是這樣的(在基於成本的規劃師),這不是我第一次添加一個明確的USING INDEX,當它應該選擇它(這就是爲什麼我在這裏檢查)。 –
我想我已經看到了一個答案,然後提到標籤集的大小可能與成本計劃人員計算何時使用索引進行查找有關,我會盡量在稍後查找。可能是索引查找的好處可能更昂貴,或者可能無法爲給定標籤的小組節點提供任何顯着增益的情況。 – InverseFalcon