5

すべての PK が GUID であるデータベースがあり、ほとんどの PK はテーブルのクラスター化インデックスでもあります。これが悪いことであることはわかっています (GUID のランダムな性質のため)。したがって、ここには基本的に 2 つのオプションがあるようです (GUID を PK として完全に破棄することを除けば、これはできません (少なくとも現時点ではできません))。

  • この記事で詳しく説明されているように、GUID 生成アルゴリズムを NHibernate が使用するアルゴリズムなどに変更することもできます。
  • 最も頻繁に使用されているテーブルについては、別のクラスター化インデックス (IDENTITY 列など) に変更し、「ランダムな」GUID を PK として保持することができます。

そのようなシナリオで一般的な推奨事項を与えることは可能ですか?

問題のアプリケーションには 500 以上のテーブルがあり、最大のものは現在約 1,500 万行、いくつかのテーブルは約 500,000 行で、残りは大幅に少なくなります (ほとんどのテーブルは 10K をはるかに下回っています)。

さらに、アプリケーションはすでにいくつかの顧客サイトにインストールされているため、既存の顧客への悪影響を考慮する必要があります。

ありがとう！

4

2 に答える 2

7

私の意見は明確です。クラスタリング キーには INT IDENTITY を使用してください。これは、次の理由から、群を抜いて最適なクラスタリング キーです。

  • 小さな
  • 安定 (決して変更しないでください)
  • 個性的
  • 増え続ける

シーケンシャル GUID は、通常のランダム GUID よりもはるかに優れていますが、それでも INT の 4 倍 (16 対 4 バイト) であり、テーブルに多数の行があり、クラスター化されていないインデックスが多数ある場合は、これが要因になります。あのテーブルにも。クラスター化キーはすべての非クラスター化インデックスに追加されるため、サイズが 4 バイトに対して 16 バイトになるという悪影響が大幅に増加します。バイトが増えるということは、ディスク上および SQL Server RAM 内のページが増えることを意味するため、ディスク I/O と SQL Server の作業が増えることになります。

必要に応じて、GUID を主キーとして保持することは間違いありませんが、その場合は、別の INT IDENTITY をそのテーブルに追加し、その INT をクラスタリング キーにすることを強くお勧めします。私自身、多数の大きなテーブルでこれを行ったところ、驚くべき結果が得られました。テーブルの断片化は 99 パーセントから数パーセントに減少し、パフォーマンスは大幅に改善されました。

GUID が SQL Server のクラスタリング キーとしてよくない理由については、Kimberly Tripp の優れたシリーズをご覧ください。

マルク

于 2010-04-09T08:57:16.750 に答える
3

guid 世代を順次 guid 世代に簡単に変更できる場合は、おそらくそれがすぐに役立つオプションです。シーケンシャル GUID は、クラスター化されたインデックスとして残りながら、テーブルの断片化を停止します。ただし、シーケンシャル guid の主な欠点は、推測可能になることであり、これは望ましくないことが多く、最初に guid が使用される理由です。

クラスター化された主キーの ID ルートを下ってから、guid 列のインデックスだけを取得すると、guid インデックスで多くの断片化が発生します。ただし、テーブルが断片化されなくなるという事実は、大きなメリットになります。

最後に、今のところこれを行うことはできないと言ったことは知っていますが、GUID をインデックスとして使用する必要がまったくない場合は、これらの問題をすべて削除します。

于 2010-04-09T09:03:04.850 に答える