FKをチェックする必要があるため、挿入、更新、および削除でパフォーマンスがわずかに低下します。個々のレコードの場合、これは通常、テーブルに関連付けられたFKの数がばかげている場合を除いて、気付かないほどわずかです（2以外の100個のテーブルをチェックするのに明らかに時間がかかります）。整合性のないデータベースは信頼できないため、役に立たないため、これは悪いことではなく良いことです。誠実さをスピードと引き換えにすべきではありません。このパフォーマンスへの影響は、通常、実行計画を最適化するための優れた機能によって相殺されます。
約900万のレコードとFKが必要な場所にある中規模のデータベースがあり、パフォーマンスの低下に気付くことはめったにありません（100をはるかに超える外部キーを持つ1つの不適切に設計されたテーブルを除いて、これからレコードを削除するのは少し遅いです。チェックする必要があります）。私が知っているほとんどすべてのdbaは、テラバイトサイズの大規模なデータベースを扱っており、大規模なデータセットでの高性能の真の必要性は、データベースの整合性が重要であるため、外部キーの制約を要求します。テラバイトサイズのデータベースを使用している人がパフォーマンスへの影響を非常に小さくする余裕がある場合は、そうすることができます。
FKは自動的にインデックス付けされないため、インデックス付けされていない場合、パフォーマンスの問題が発生する可能性があります。
正直なところ、私はあなたのデータベースのコピーを取り、適切にインデックス付けされたFKを追加し、FKなしのデータベースからの同じものと比較して、それらのテーブルから挿入、削除、更新、および選択する時間差を示します。パフォーマンスに影響を与えないことを示します。次に、関連するPKが存在しなくなったために意味がなくなった孤立したレコードを示すクエリの結果を表示します。財務情報を含むテーブルにこれを表示することは特に効果的です（「顧客と関連付けることができない注文が2700ある」と、経営陣は立ち上がって注意を向けます）。