GUIDとINTのクラスター化されたインデックス付きの列、特にこれらの列の結合の場合）にパフォーマンスの違いはありますか？
基本的にタイトルが言うこと：GUID列とINT列でのクラスター化インデックスのクラスター化インデックスを使用する場合、特にこれらの列があなたの結合述語？
編集：明確にするために、私は常に、GUIDが結合述語で使用された場合、通常、INTよりもパフォーマンスが悪いと想定していました。 GUIDはINTのデータサイズの4倍ですが、「フードの下」で何が起こっているのか、そしてGUIDのパフォーマンスが低下する原因となるものを本当に理解するように質問しました。インデックスが再構築され、2つのタイプ間の断片化の違いが最小限になります。
GUIDはINTのデータサイズの4倍ですが、「フードの下」で何が起こっているのか、そしてGUIDのパフォーマンスが低下する原因となるものを本当に理解するように質問しました。インデックスが再構築され、2つのタイプ間の断片化の違いが最小限になります。
私が引用したように、問題は主にあなたがここで始めたものだと言います：UNIQUEIDENTIFIERはINTより4倍大きいです（4と比較して16バイト）。これにより、3つの点でパフォーマンスが低下します（フラグメンテーションは明確に説明されているため、断片化は無視しています）。
比較されるすべてのビットは、実行する別のことです。 CPUの処理が増えると、時間がかかります。その時間は、100行を見ても、最新のシステムでは気付かれません。しかし、100万行以上ですか？今、あなたは（バイトの観点から）、1600万のものを比較することと400万のものだけを比較することについて話している。
メモリは自由ではありません。お金の観点からも、割り当てと割り当て解除に費やされる時間の観点からもです。行を結合するには、それらの行を含むデータページをメモリ（バッファプール）に読み込む必要があります。メモリは無限ではありません（特に、Standard EditionまたはExpress Editionを使用している場合）。 1つの操作で使用するメモリが多いほど、他の同時操作で使用できるメモリが少なくなります。ただし、メモリが無限大であっても、それらの値をメモリにロードして比較できるようにするには時間がかかります。当然、1600万バイトのロードには、400万バイトのロードより時間がかかります。
ディスクは無料ではありません。SSDを使用しても、物理I/Oは依然として費用がかかるため、物事がメモリにキャッシュされます。データページはわずか8kbです。 16バイトの値がある場合は、4バイトの値を持つ場合と比較して、その8 kbのデータページに収まる行数が減少します。テーブルが使用するデータページが多いほど、同じ数の行を読み書きするために必要な物理I/Oが多くなります。
関連する問題はインデックスにあります。結合する列にインデックスを付ける可能性があります。メインテーブルと同じ問題：ページあたりのインデックス行が少ないほど、インデックスに必要なページが多くなるため、特定の操作の影響を受けるすべてのインデックスの読み取りと書き込みに費やす時間が長くなります（テーブルの新しい行で新しい行を作成する必要があります）そのテーブルのすべてのインデックス（除外するフィルター処理されたインデックスを除く）。クラスター化インデックスについて話していると仮定すると、クラスター化インデックスキーはすべての非クラスター化インデックスにコピーされます）