本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 偏好查詢中的定向至雙向邊緣
<a name="best-practices-opencypher-directed-edges"></a>

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
```

當受到最多限制的節點未放在模式中的第一位時，引擎必須執行額外的工作，因為它無法最佳化查詢，而且必須執行其他查詢才能得出結果。