個別のスキーマを使用すると、SQL Server 2008のパフォーマンスにどのような影響がありますか？

SQL Server 2008データベースで、目的の異なるオブジェクトに個別のスキーマを使用したい。今のところ、テーブルやストアドプロシージャの目的を示すためにかなり気の遠くなるような命名規則を使用しており、プレフィックスは、一意の名前の始まりを確認する前に5つまたは6つのxharacterをスキャンする必要があることを意味します。UIを駆動するためだけに使用されるテーブル（メニュー、ユーザー別の役割など）と、ディメンションテーブルとファクトテーブルなどのスキーマに別々のスキーマを使用したいと思います。

私の質問は、複数のスキーマ（スキーマ？）を使用することによるパフォーマンスへの影響はありますか？

コーディングスタイルによっては、小さなものではありますが、クエリオプティマイザーのパフォーマンスに影響を与える可能性があります。スキーマなしでテーブルを参照する場合、オプティマイザはまずユーザーのデフォルトスキーマ（存在する場合）内のテーブルをチェックし、次にdbo。を使用してテーブルを特定する必要があります。テーブルをschema.tableとして明示的に参照する場合、これはおそらくいずれにしても良い方法であり、この小さなオーバーヘッドでさえ回避されます。

パフォーマンスに違いはありません。しかし、あなたは今スキーマを使用しています（たとえあなたがそれを知らなくても）。

スキーマ修飾されていないテーブル、ストアドプロシージャ、UDFなどのスキーマオブジェクトへの参照を使用すると、パフォーマンスに影響があります。参照は常にスキーマで修飾する必要があります。このような修飾されていない参照は解決する必要があり、それは次のように行われます。

• 最初に、セッションが確立された資格情報を持つユーザーのデフォルトスキーマの下で、同じ名前とタイプのオブジェクトを探します（例：）jsmith。見つかった場合、そのインスタンスが使用されます。
• それ以外の場合は、スキーマの下で同じ名前とタイプのオブジェクトを探しますdbo。

これにはいくつかの影響があります：

• ほとんどの場合、参照がスキーマ修飾されている場合、必要な単一のルックアップではなく、参照を解決するために2つのルックアップが必要です。
• クエリ/ストアドプロシージャ/ユーザー定義関数がバインドされたときに取得された実行プランは、キャッシュして再利用できません。

何かが壊れたときにのみ（苦痛に）見つかる最後の効果は、特定のクエリまたはストアドプロシージャから異なるユーザーが異なる結果を得る可能性があることです。次のようなものselect * from foo join barが、db所有者として私にとってはうまく機能する場合があります。同じデータベースに自分のスキーマ（）でjsmith名前が付けられたテーブルを誤って作成したかどうかに関係なく、壊れる可能性があります。foojsmith.foo

このため、あまりにも、createそしてdropステートメントが作成または削除されるオブジェクトの名前をスキーマ修飾する必要があります。