外部キーはクエリのパフォーマンスを向上させますか？

ProductsとProductCategoriesという2つのテーブルがあるとします。両方のテーブルは、CategoryIdに関係があります。そしてこれがクエリです。

SELECT p.ProductId, p.Name, c.CategoryId, c.Name AS Category
FROM Products p
INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
WHERE c.CategoryId = 1;

実行プランを作成すると、予想どおり、テーブルProductCategoriesがクラスターインデックスのシークを実行します。しかし、テーブル製品の場合、クラスターインデックススキャンを実行するので、疑問に思います。FKがクエリのパフォーマンス向上に役立たないのはなぜですか？

したがって、Products.CategoryIdにインデックスを作成する必要があります。再度実行プランを作成すると、両方のテーブルがインデックスシークを実行します。また、推定されるサブツリーのコストが大幅に削減されます。

私の質問は：

1. FKは関係の制約に役立ちますが、他に何か便利なことはありますか？クエリのパフォーマンスは向上しますか？

2. すべてのテーブルのすべてのFK列（Products.CategoryIdなど）にインデックスを作成する必要がありますか？

外部キーは参照整合性ツールであり、パフォーマンスツールではありません。少なくともSQL Serverでは、FKを作成しても関連するインデックスは作成されません。ルックアップ時間を改善するには、すべてのFKフィールドにインデックスを作成する必要があります。

外部キーはパフォーマンスを改善（および害）する可能性があります

1. ここで述べたように：外部キーはパフォーマンスを向上させます

2. 検索を減らすために、常にFK列にインデックスを作成する必要があります。SQL Serverはこれを自動的に行いません。

編集する

リンクが無効になっているように見える（気づくためにChrisにkudosしている）ため、以下に外部キーがパフォーマンスを改善（および害）する理由の要点を示します。

外部キーはパフォーマンスを改善できますか

外部キー制約は、データの読み取り時のパフォーマンスを向上させますが、同時に、データの挿入/変更/削除時のパフォーマンスを低下させます。

クエリを読み取る場合、外部キー制約は事前宣言されたルールであるため、オプティマイザは外部キー制約を使用して、より効率的なクエリプランを作成できます。たとえば、オプティマイザは外部キー制約のためにプランの特定の部分を実行する必要がないことを確認できるため、これには通常、クエリプランの一部をスキップすることが含まれます。

外部キーは、データベースの整合性を確保するためのDBMSの概念です。

パフォーマンスへの影響/改善は、使用されているデータベーステクノロジーに固有のものであり、外部キーの目的に二次的なものです。

SQL Serverでは、すべての外部キーに少なくとも非クラスター化インデックスが設定されていることを確認することをお勧めします。

これで問題が解決することを願っていますが、詳細をリクエストしてください。

パフォーマンスの最善策は、頻繁に使用するフィールドでインデックスを使用することです。SQL Serverを使用する場合、プロファイラーを使用して特定のデータベースをプロファイリングし、出力するファイルを取得して、チューニングウィザードを使用して、インデックスを配置する場所に関する推奨事項を受け取ることができます。また、プロファイラーを使用して実行時間の長いストアドプロシージャをフラッシュするのも好きです。毎週公開している最悪の違反者リストのトップ10を持っています。

これを使用して、クエリをより効率的にすることができます。SQL Serverでクエリを再構築して、内部結合の代わりに外部結合を使用することができます。これにより、SQLサーバーが列にnullがあるかどうかを確認する必要がなくなります。外部キーの関係がすでにそれを強制しているので、その修飾子を入れる必要はありません。

したがって、この：

    select p.ProductId, p.Name, c.CategoryId, c.Name AS Category 
from Products p inner join ProductCategories c on p.CategoryId = c.CategoryIdwhere c.CategoryId = 1;

これになる：

SELECT p.ProductId, p.Name, c.CategoryId, c.Name AS Category 
FROM ProductCategories c 
LEFT OUTER JOIN Products P ON
c.CategoryId = p.CategoryId 
WHERE c.CategoryId = 1;

これは必ずしも小さなクエリで大きなパフォーマンスを発揮するわけではありませんが、テーブルが大きくなると、より効率的になります。

MySQL 5.7の場合、複数の結合を含むクエリを驚くほど高速化できます。

'explain'を使用してクエリを理解し、キーがまったく使用されていない4〜5個のテーブルを結合していることがわかりました。これらのテーブルに外部キーを追加するだけで、ロード時間は90％短縮されました。5秒以上かかったクエリの所要時間が500ミリ秒以下になりました。

それはすごい改善です！

そして、他の人が述べたように、関係の完全性を保証するという追加のボーナスを得ます。

これに加えて、参照整合性を保証することには、それ自体のパフォーマンス上の利点もあります。これには、外部キーを持つテーブルが外部テーブルで「最新」であることを保証するという2次的な効果があります。ユーザーテーブルとコメントテーブルがあり、コメントテーブルで統計を行っているとします。おそらく、ユーザーを完全に削除すると、ユーザーのコメントも不要になります。

テーブルに外部キーを追加しても、パフォーマンスは向上しません。単に、ProductCategoriesテーブルデータベースにレコードを挿入する場合、外部キー列が製品テーブルの主キー値に存在する値を見つけようとすると、このルックアップは、操作は、ProductCategoriesテーブルに新しいエントリを追加するたびにデータベースのオーバーヘッドになります。したがって、外部キーを追加してもデータベースのパフォーマンスは向上しませんが、データベースの整合性は考慮されます。はい、プログラム内のデータベースにレコードが存在することを確認するために多くのクエリを実行する代わりに、外部キーを使用して整合性を確認している場合は、dbのパフォーマンスが向上します。

SQLサーバーについてはあまり知りませんが、Oracleの場合、外部キー列があると、データ読み込みのパフォーマンスが低下します。これは、データベースが挿入ごとにデータの整合性をチェックする必要があるためです。そして、はい、既に述べたように、外部キー列にインデックスを付けることは良い習慣です。

SQL Server 2008以降、外部キーは、データベースエンジンがクエリの最適化を選択する方法に影響を与えることにより、パフォーマンスに影響を与える可能性があります。次の記事のStar Join Heuristicsを参照してください。https：//technet.microsoft.com/en-us/library/2008.04.dwperformance.aspx