データベース テーブルにいくつかのファイル メタデータが格納されているとします。各ファイルは、グローバルに一意のファイル ID で識別できます。各ファイルは、グローバルに一意の ID を持つフォルダー (複数のファイルを保存できる) 内にあります。そのため、テーブルには、他の列とともに、2 つの一意の識別子があります。
FileID (GUID/uniqueidentifier)
FolderID (GUID/uniqueidentifier)
FileIDテーブル内のそれぞれは異なる (ランダムな GUID が割り当てられている) はずですが、同じものFolderIDが複数回表示される可能性があることに注意してください。特定のファイル レコードを取得するには、以下のみFileIDを使用できます。
SELECT * FROM table WHERE FileID=...
私の主な質問は、検索するレコードの数を制限するために明示的に指定することで、パフォーマンス上の利点はありFolderIDますか? FileIDこのような：
SELECT * FROM table WHERE FileID=... AND FolderID=...
どちらの方法を使用する必要がありますか、最初のもの、2番目のもの、それはまったく問題ですか? インデックス作成、フィールドカーディナリティなどの特定の条件に依存しますか? このようなクエリの最適化に関して、SQL Server はどれほど賢いのでしょうか? 条件の順序は関係がありますか (つまりWHERE FileID=... AND FolderID=...vs WHERE FolderID=... AND FileID=...)? 表面的に指定することの唯一の潜在的な利点はFolderID、非常にありそうにないFileIDGUID 衝突に対する保護のようです。
私の最初の推測 (クエリが内部でどのように実行されるかはわかりません) は次のようなものでした: ブロック サイズを無視し、両方のフィールドにインデックスが付けられていると仮定すると (B ツリーまたはそのようなlogN構造を想定)、最初のケース (のみを使用FileID) で検索Xファイルが保存されるときの時間計算量は次のようになります。log2(X)
X ファイルがdフォルダーに均一に分散されている場合、各フォルダーにはfファイルが含まれ、検索の複雑さは次のようになりますlog2(d) + log2(f) = log2(d*f) = log(X)。FolderIDsこれは、が最初に検索され、次に のサブセットが検索されることを前提としていFileIDsます。どちらのフィールドもインデックス化されていない場合、明らかな違いはありません。
ただし、 is のみFileIDがインデックス付けされていて、 is がインデックス付けされていないとします ( N/2FolderID平均複雑度の線形検索が適用されます)。クエリに 2 番目の形式を使用すると、検索の複雑さが、withのみを使用する場合よりも大幅に悪化する可能性があります。たとえば、X =の場合です。 100 万個のファイルがd = 50000 フォルダーに分散されます。つまり、フォルダーごとにf = 20 ファイルです。d/2 + log2(f)FiledIDlog2(X)
SQL Server はこのようなことを検出し、それに応じて動作しますか?