本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Neptune 執行查詢最佳化時，雙向邊緣會使建立最佳化查詢計劃變得困難。次佳計劃要求引擎執行不必要的工作並導致更差的效能。
因此，盡可能使用定向邊緣而不是雙向邊緣。例如，使用：
MATCH p=(:airport {code: 'ANC'})-[:route]->(d) RETURN p)
而不是：
MATCH p=(:airport {code: 'ANC'})-[:route]-(d) RETURN p)
大多數資料模型實際上不需要周遊兩個方向的邊緣，因此查詢可以透過切換到使用定向邊緣來達到大幅的效能改進。
如果您的資料模型確實需要周遊雙向邊緣，則使 MATCH 模式中的第一個節點 (左側) 成為篩選最嚴格的節點。
舉個例子，「為我找到所有往返 ANC 機場的 routes」。編寫此查詢，從 ANC 機場開始，如下所示：
MATCH p=(src:airport {code: 'ANC'})-[:route]-(d) RETURN p
引擎可以執行最少的工作量來滿足查詢，因為受到最多限制的節點會放置在模式中作為第一個節點 (左側)。然後，引擎可以最佳化查詢。
這比在模式結束時篩選 ANC 機場更好，如下所示：
MATCH p=(d)-[:route]-(src:airport {code: 'ANC'}) RETURN p
當受到最多限制的節點未放在模式中的第一位時，引擎必須執行額外的工作，因為它無法最佳化查詢，而且必須執行其他查詢才能得出結果。
