2 に答える
いろいろと考えてくださったようです。私や他の誰かが何を言おうと、確実に知る唯一の方法は自分で測定することです. その場合、これは SQL Azure の問題ではなく、より一般的な SQL Server クエリ最適化の問題になります。
状況に応じて、開始するためのヒントがいくつかあります。LINQ を使用しているため、SQL で実行されている実際のクエリに直接アクセスすることはできません。クエリがどのように表示されるかはわかっていると思われるかもしれませんが、使用している EF のバージョンによっては、クエリの構造について興味深い決定を下すことができます。どのクエリが実行されているかを正確に調べるには、SQL Profiler またはExtended Eventsを使用する必要があります。SQL プロファイラーは SQL Azure に対しては機能しないため、拡張イベントを使用するか、どこかのローカル サーバーで DB のコピーを取得し、ローカルを指すアプリケーションを実行する必要があります。これには、エクスポート データ層アプリケーションと、 SQL Server Management Studio (SSMS)の関連するインポートが非常に役立ちます。
実際のクエリを使用して、Azure のデータベースに対して SSMS で実行し、実行計画を取得できます。次に、インデックスを変更し、クエリを再度実行して、プランを比較できます。メインの開発DBをいじりたくない場合は、コマンドを使用するなど、さまざまな方法でCREATE DATABASE xxx AS COPY OF yyyy非常に簡単にコピーを作成できます。
ローカル DB で最適化を行う誘惑に駆られないでください。SQL Azure には、ほとんどのオンプレミス SQL インストールとは異なるパフォーマンス アウトラインがあります。
以上のことから、すべてのクエリに常にテナント ID が含まれる場合、クラスター化インデックスの最初の部分としてテナント ID を含めることで、クエリのパフォーマンスが向上すると期待できます。他のすべての指標については、よくわからないので、測定、測定、測定します。また、インデックスは無料で提供されるわけではないことも覚えておいてください。作成するすべてのインデックスは、書き込みパフォーマンスと DB のサイズに影響を与えます。
最後に、PK に guid を使用することについて心配する必要はありません。DB が十分に大きくなり、テナント ID でフェデレートする必要がある場合 (構造は非常にうまく処理されるように見えます)、IDENTITY 列はオプションにならなくなります。