SQL Server 2016内でテーブルのシノニムは費用対効果が高い
私たちの新しいプロジェクトの1つでは、別のデータベースを参照するテーブルに多くの同義語を使用することを考えており、それが何をするのか、どのように使用するのかについては十分に理解しています。しかし、私たちが知らないことは、SQLサーバーの全体的なパフォーマンスに隠れたオーバーヘッドがあるかどうかです。まったくない場合。
this によると-
シノニムは既存のデータベースオブジェクトの抽象化/代替名であるため、テーブルの場合、インデックスの動作は基礎となるオブジェクトの動作と同じです。つまり、実行プランが生成されると、テーブルの使用に関係なく同じプランが生成されます。名前または対応する同義語。
通常のオブジェクトとシノニムの両方を使用するときに実行プランを確認して、同じプランを生成するかどうかを確認できます。
これ 投稿には同様の質問があります：
同義語の使用はパフォーマンスにどのように影響しますか？
より具体的には、実行計画でシノニムは完全修飾名に置き換えられますか？シノニムは実際のオブジェクトに解決する必要があるように思われるので、キャッシュされたプランを持たないクエリやプロシージャには、シノニムを実際のオブジェクトにマッピングするための追加の手順が必要になります。これで非常に小さなパフォーマンスヒットがあると思います。おそらく、シノニムが別のデータベース上のオブジェクトを参照する場合はわずかに大きいヒットであり、別のサーバー上にある場合はわずかに大きいヒットです。
与えられた答えは
それらは、ビューが展開されるのと同じように、クエリ実行のバインド段階でスワップアウトされます。これは、実行プランが生成される最適化フェーズの前に発生するため、クエリテキストにシノニムへの参照が表示されている間は、シノニムが指すオブジェクトへの参照のみが実行プランの演算子に表示されます。
同義語の使用に関連する可能性のあるパフォーマンスへの影響は、それを呼び出したい場合でも、まったく心配する必要はありません。
きっと Paul White （または別の専門家が決定的な応答を提供するでしょう）。
「別のデータベース」と言うとき、同じインスタンス内、つまりdatabase2.schema.tablenameを意味しますか？もしそうなら、あなたは大丈夫です。オーバーヘッドはごくわずかです。データベース間の権限の問題に注意してください。
または、別のインスタンス、つまりinstance2.database2.schema.tablenameを意味しますか？もしそうなら、これは特にオブジェクト/シノニムという名前の4つの部分の複数の結合に対してひどく悪い場合があります。 https://blogs.msdn.Microsoft.com/sqlsakthi/2011/05/08/best-performer-distributed-query-four-part-or-openquery-when-executing-linked-server-queries -in-sql-server / 少し詳細ですが、OPENQUERYまたは同様のもの（EXECUTE ATも機能します））を使用してSQLステートメント全体を出荷することになります。