我正在redisgraph使用ioredis. 該查詢在具有數百萬個節點的資料庫上運行 3 到 6 秒。它基本上通過在不同節點上添加以下匹配和位置多次來按不同的關系計數過濾（b：brand）。
(:brand) - 1mil nodes
(:w) - 20mil nodes
(:e) - 10mil nodes
// matching b before this codeblock
MATCH (b)-[:r1]->(p:p)<-[:r2]-(w:w)
WHERE w.deleted IS NULL
WITH count(DISTINCT w) as count, b
WHERE count >= 0 AND count <= 10
完整的查詢看起來像這樣。
MATCH (b:brand)
WHERE b.deleted IS NULL
MATCH (b)-[:r1]->(p:p)<-[:r2]-(w:w)
WHERE w.deleted IS NULL
WITH count(DISTINCT w) as count, b
WHERE count >= 0 AND count <= 10
MATCH (c)-[:r3]->(d:d)<-[:r4]-(e:e)
WHERE e.deleted IS NULL
WITH count(DISTINCT e) as count, b
WHERE count >= 0 AND count <= 10
WITH b ORDER by b.name asc
WITH count(b) as totalCount, collect({id: b.id)[$cursor..($cursor $limit)] AS brands
RETURN brands, totalCount
我該如何優化這個查詢，因為它真的很慢？
uj5u.com熱心網友回復：
一些想法：
- 屬性查找很昂貴；有沒有辦法繞過所有 .deleted 檢查？
- 如果可能，您能避免命名 r1、r2 等嗎？當它不必檢查關系型別時會更快。
- 您實際上是在多次遍歷整個圖表。如果路徑 b-->p<--w 和 c-->d<--e 不重疊，您可以將它們都包含在 match 陳述句中，用逗號分隔，并同時聚合兩個計數
- 我不知道它是否會有很大幫助，但是您不需要命名 p 和 d，因為您從不提及它們
- 這是一個很小的改進，但我沒有理由檢查 count >= 0
另外，我相信你有你的理由，但為什么 c-->d<--e 路徑很重要？如果它是 b-->d<--e 來鏡像第一部分，這對我來說會更有意義。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/519869.html
標籤：表现优化雷迪斯暗号再版图
上一篇：連接和分組熊貓資料幀的有效方法