SQL Serverで外部キーを使用すると、パフォーマンスが大幅に低下しますか？
私は、データベースで外部キーを使用できるように上司を説得するために最善を尽くしています-これまでのところ運がありません。
彼は、かなりのパフォーマンスが必要であると主張し、無効な参照をときどきクリーンアップする仕事があるだけだと言います。
明らかに、これは実際には機能せず、データベースは無効な参照で溢れています。
外部キーを使用してもパフォーマンスに大きな影響がないことを証明する比較、ベンチマークなどを知っている人はいますか？ （私は彼を納得させることを願っています）
FKをチェックする必要があるため、挿入、更新、および削除でパフォーマンスがわずかに低下します。個々のレコードの場合、これは通常、テーブルに関連付けられたFKの数がばかげている場合を除いて、気付かないほどわずかです（2以外の100個のテーブルをチェックするのに明らかに時間がかかります）。整合性のないデータベースは信頼できないため、役に立たないため、これは悪いことではなく良いことです。誠実さをスピードと引き換えにすべきではありません。このパフォーマンスへの影響は通常、実行プランを最適化する優れた機能によって相殺されます。
中規模のデータベースには約900万のレコードとFKがあり、パフォーマンスの低下に気付くことはめったにありません（100をはるかに超える外部キーを持つ1つの不適切に設計されたテーブルを除いて、これからレコードを削除するのは少し遅いです。チェックする必要があります）。私が知っているほとんどすべてのdbaは、テラバイトサイズの大規模なデータベースを扱っており、大規模なデータセットでの高性能の真の必要性は、整合性がデータベースの鍵であるため、外部キーの制約を要求します。テラバイトサイズのデータベースを使用している人が、パフォーマンスへの影響を非常に小さくする余裕がある場合は、そうすることができます。
FKは自動的にインデックス付けされません。インデックス付けされていない場合、パフォーマンスの問題が発生する可能性があります。
正直なところ、私はあなたのデータベースのコピーを取り、適切にインデックス付けされたFKを追加し、FKのないデータベースからの同じものと比較して、それらのテーブルから挿入、削除、更新、および選択する時差を示します。パフォーマンスに影響を与えないことを示します。次に、関連するPKが存在しなくなったために意味がなくなった孤立したレコードを示すクエリの結果を表示します。財務情報を含むテーブルにこれを表示することは特に効果的です（「顧客に関連付けることができない注文が2700ある」と、経営陣は立ち上がって注意を向けます）。
From Microsoftのパターンと実践：第14章SQL Serverのパフォーマンスの向上 ：
主キーと外部キーがデータベーススキーマの制約として定義されている場合、サーバーはその情報を使用して最適な実行プランを作成できます。
これは技術的な問題というよりは政治的な問題です。プロジェクト管理者がデータの整合性を維持することに何の価値も見当たらない場合は、別のプロジェクトに参加する必要があります。
上司があなたが何千もの無効な参照を持っていることをまだ知らないか気にしない場合、あなたがそれについて彼に話すという理由だけで彼は気にかけ始めるつもりはありません。良い戦いをして「正しいこと」をするように促そうとしている他のポスターに同情しますが、私は以前に何度も試しましたが、実際にはうまくいきません。デビッドとゴリアテの物語は良い読み物になりますが、実際の生活ではそれは命題を失っています。
外部キーを使用してもパフォーマンスに大きな影響がないことを証明する比較、ベンチマークなどを知っている人はいますか？ （私は彼を納得させることを願っています）
私はあなたがこれについて間違った方法で行っていると思います。ベンチマークは誰にも納得させません。
最初に、外部キー制約を使用しないことに起因する問題を明らかにする必要があります。 「無効な参照を一掃する」のにかかる作業量を定量化してみてください。さらに、これらのエラーが原因でビジネスプロセスに発生するエラーの数を測定してみてください。あなたがそれにドルの金額を付けることができれば-さらに良いです。
ベンチマークとして、ワークロードを把握し、最も頻繁に実行される操作の種類を特定する必要があります。次に、テスト環境をセットアップし、外部キーを配置してそれらの操作を再生します。次に、比較します。
個人的には、データベースで実行されているアプリケーションの知識がなければ、外部キーはパフォーマンスを犠牲にしないとすぐに主張することはありません。特に、複合自然主キーと組み合わせてカスケード削除や更新がある場合、私は個人的にパフォーマンスの問題、特にカスケード操作の副作用によるタイムアウトまたはデッドロックされたトランザクションを恐れます。
しかし、誰もあなたに言うことはできません-あなたはあなたのデータ、あなたのワークロード、あなたの同時ユーザーの数、あなたのハードウェア、あなたのアプリケーションであなた自身をテストしなければなりません。
パフォーマンスを気にすることは問題ありませんが、偏執的な決定を下すことは問題ではありません。
自分で結果を表示するベンチマークコードを簡単に作成できますが、最初に上司が懸念しているパフォーマンスを調べ、それらの指標を正確に詳しく説明する必要があります。
無効な参照に関する限り、外部キーでnullを許可しない場合、無効な参照を取得することはありません。存在しない無効な外部キーを割り当てようとすると、データベースが認識されます。 「null」が必要な場合は、キーを「UNDEFINED」などに割り当て、それをデフォルトのキーにします。
最後に、データベースの正規化の問題を上司に説明します。これは、この問題が外部キーのパフォーマンスよりも問題になることがすぐにわかると思います。
コストの重要な要因は、外部キーが参照するインデックスのサイズです-それが小さくて頻繁に使用される場合、パフォーマンスへの影響は無視でき、大きくてあまり使用されないインデックスはより大きな影響を及ぼしますが、外部キーが反対の場合クラスター化インデックス、それでも大ヒットにはならないはずですが、@ RonaldBoumanは正しいです-確認するためにテストする必要があります。