特にパフォーマンスに関して、GUIDを主キーとして使用するためのベストプラクティスは何ですか？

ほとんどすべてのテーブルで主キーとしてGUIDを使用するアプリケーションがあり、GUIDを主キーとして使用するとパフォーマンスに関する問題があることを読みました。正直なところ、問題はありませんでしたが、新しいアプリケーションを開始しようとしていて、GUIDを主キーとして使用したいのですが、複合主キー（GUIDと別のフィールド）を使用することを考えていました。 。）

「本番」、「テスト」、「開発」データベースなどの異なる環境があり、データベース間のデータの移行にも適しているため、GUIDを使用しています。

Entity Framework 4.3を使用し、データベースに挿入する前に、アプリケーションコードでGuidを割り当てたいと思います。（つまり、SQLにGuidを生成させたくありません）。

このアプローチに関連する想定されるパフォーマンスへの影響を回避するために、GUIDベースの主キーを作成するためのベストプラクティスは何ですか？

GUIDは主キーの自然な選択のように思えるかもしれませんが、本当に必要な場合は、テーブルの主キーにGUIDを使用するように主張することができます。特にお勧めしない限り、SQLサーバーはデフォルトでGUID列をクラスタリングキーとして使用しないことを強くお勧めします。

あなたは本当に2つの問題を分けておく必要があります：

1. 主キーは、一意かつ確実に、テーブル内のすべての行を識別すること、候補キーのいずれか-論理的構築物です。これは本当に何でもかまいません。INT、GUID文字列が-あなたのシナリオのための最も理にかなっているものを選びます。

2. クラスタ化キー（表の「クラスタ化インデックス」を定義する列または列） -これは、物理 -ストレージ関連のもの、そしてここで、小型、安定した、増え続けるデータ型は、あなたの最高のピックであるINTか、BIGINTあなたのようデフォルトのオプション。

デフォルトでは、SQL Serverテーブルの主キーはクラスタリングキーとしても使用されますが、そのようにする必要はありません。以前のGUIDベースのプライマリ/クラスター化キーを2つの別々のキーに分割すると、パフォーマンスが大幅に向上します。GUIDのプライマリ（論理）キーと、別のINT IDENTITY(1,1)列のクラスター化（順序）キーです。

以下のようキンバリーメーカーTripp -インデックスの女王-などが非常に多くの時間を述べている- GUIDクラスタリング・キーは、そのランダム性に起因しているため、最適ではないとして、それは大規模なページとインデックスの断片に、一般的に悪いパフォーマンスにつながります。

はい、知っています-あります newsequentialid()ています。SQLServer 2005以降にもありますが、それでも完全にシーケンシャルではなく、したがって、同じ問題がGUID-それほど顕著ではありません。

次に、考慮すべき別の問題があります。テーブルのクラスタリングキーは、テーブルのすべての非クラスタ化インデックスのすべてのエントリにも追加されます。したがって、できるだけ小さくする必要があります。通常、INT20億行以上の行があれば、ほとんどのテーブルで十分です。GUIDクラスタリングキーとしてのと、ディスクとサーバーメモリに数百メガバイトのストレージを節約できます。

クイック計算- INT対GUID一次およびクラスタリングのキーのように：

• 1'000'000行のベーステーブル（3.8 MB対15.26 MB）
• 6つの非クラスター化インデックス（22.89 MB対91.55 MB）

合計：25 MB対106 MB-これは1つのテーブルにあります！

もう少し考えるべき食べ物-Kimberly Trippによる優れたもの-読んで、もう一度読んで、消化してください！SQL Serverのインデックス作成の福音です。

• 主キーまたはクラスター化されたキー、あるいはその両方としてのGUID
• クラスター化インデックスの議論は続く
• 増え続けるクラスタリングキー-Clustered Index Debate ..........再び！
• ディスク容量は安いです-それはポイントではありません！

PS：もちろん、数百行または数千行だけを扱っている場合、これらの引数のほとんどは実際にはそれほど大きな影響を与えません。ただし、数万行または数十万行に到達した場合、または数百万行でカウントを開始した場合、これらのポイントは非常に重要であり、理解することが非常に重要になります。

更新：あなたはあなたの持っているしたい場合はPKGUID、あなたの主キー（はなく、あなたのクラスタリング・キー）、および別の列としての列をMYINT（INT IDENTITY）あなたのクラスタ化キーとして-これを使用します：

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )

ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)

CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

基本的には、PRIMARY KEY制約であることを明示的に伝える必要がありますNONCLUSTERED（そうでない場合は、デフォルトでクラスター化インデックスとして作成されます）。次に、次のように定義されている2番目のインデックスを作成します。CLUSTERED

これは機能します-パフォーマンスのために「再設計」する必要がある既存のシステムがある場合、これは有効なオプションです。新しいシステムの場合、ゼロから始めて、レプリケーションシナリオでない場合は、常にID INT IDENTITY(1,1)クラスター化された主キーとして選択します-何よりもはるかに効率的です！

私は2005年以来、GUIDをPKとして使用しています。この分散データベースの世界では、分散データをマージするのが絶対に最善の方法です。結合されたテーブル間でintが一致することを心配することなく、マージテーブルを起動して忘れることができます。GUID結合は心配することなくコピーできます。

これはGUIDを使用するための私のセットアップです：

1. PK = GUID。GUIDには文字列と同様にインデックスが付けられるため、行数が多いテーブル（5,000万を超えるレコード）では、テーブルのパーティション分割またはその他のパフォーマンステクニックが必要になる場合があります。SQL Serverは非常に効率的になっているため、パフォーマンスの懸念はますます少なくなります。

2. PK Guidは非クラスター化インデックスです。NewSequentialIDでない限り、GUIDをクラスター化しないでください。しかし、それでも、サーバーを再起動すると、注文に大きな障害が発生します。

3. ClusterID Intをすべてのテーブルに追加します。これはCLUSTEREDインデックスです...テーブルを注文します。

4. ClusterID（int）での結合の方が効率的ですが、私は2,000万〜3,000万のレコードテーブルを使用しているため、GUIDでの結合はパフォーマンスに目に見える影響を与えません。最大のパフォーマンスが必要な場合は、ClusterIDの概念を主キーとして使用し、ClusterIDで結合します。

これが私のメールテーブルです...

CREATE TABLE [Core].[Email] (
    [EmailID]      UNIQUEIDENTIFIER CONSTRAINT [DF_Email_EmailID] DEFAULT (newsequentialid()) NOT NULL,        
    [EmailAddress] NVARCHAR (50)    CONSTRAINT [DF_Email_EmailAddress] DEFAULT ('') NOT NULL,        
    [CreatedDate]  DATETIME         CONSTRAINT [DF_Email_CreatedDate] DEFAULT (getutcdate()) NOT NULL,      
    [ClusterID] INT NOT NULL IDENTITY,
    CONSTRAINT [PK_Email] PRIMARY KEY NonCLUSTERED ([EmailID] ASC)
);
GO

CREATE UNIQUE CLUSTERED INDEX [IX_Email_ClusterID] ON [Core].[Email] ([ClusterID])
GO

CREATE UNIQUE NONCLUSTERED INDEX [IX_Email_EmailAddress] ON [Core].[Email] ([EmailAddress] Asc)

現在、EF Coreを使用してWebアプリケーションを開発しています。使用するパターンは次のとおりです。

すべてのクラス（テーブル）とint PKおよびFK。非クラスター化インデックスを含む、タイプGuid（c＃コンストラクターによって生成された）の追加の列があります。

EF内のテーブルのすべての結合はintキーを通じて管理されますが、外部（コントローラー）からのすべてのアクセスはGuidで行われます。

このソリューションでは、URLにintキーを表示せずに、モデルを整然と高速に保つことができます。

GUIDを主キーとして使用し、クラスター化インデックスを作成する場合は、デフォルトのNEWSEQUENTIALID（）値を使用することをお勧めします

このリンクは、私ができるよりも優れていることを示しており、私の意思決定に役立ちました。特別な必要がない限り、通常は主キーとしてintを選択します。また、特別な理由がない限り、SQLサーバーにこのフィールドを自動生成/維持させます。実際には、パフォーマンスの問題は、特定のアプリに基づいて決定する必要があります。ここでは、予想されるDBサイズ、適切なインデックス付け、効率的なクエリなど、さまざまな要素が影響します。人々は反対するかもしれませんが、私は多くのシナリオでどちらのオプションでも違いに気付かないと思います、そしてあなたはあなたのアプリにとってより適切なものとあなたがより簡単に、より速くそしてより効果的に開発することを可能にするものを選ぶべきです（アプリを決して完成しないなら）残りはどう違いますか:)

https://web.archive.org/web/20120812080710/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

PSなぜ複合PKを使用するのか、あるいはそれがあなたにどのような利点をもたらすと信じているのか、私にはわかりません。

ほとんどの場合、データベースのパフォーマンスに影響を与えるため、テーブルの主キーとして使用しないでください。GUIDのパフォーマンスへの影響と主キーとしての役立つリンク。

1. https://www.sqlskills.com/blogs/kimberly/disk-space-is-cheap/
2. https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/

シーケンシャルIDがあると、ハッカーやデータマイナーがサイトやデータを危険にさらすのが容易になります。WebサイトのPKを選択するときは、そのことを覚えておいてください。