可能性の重複：
How do you like your primary keys?GUID INTのIDENTITY対
私はGUIDを使用することの利点だけでなく、PKのように使用するとINTのメリットを認識してよデータベース。 GUIDは本質的に128ビットのINTであり、通常のINTは32ビットであることを考慮すると、INTはスペースセーバーです（この点はほとんどの現代システムでは一般的には間に合いませんが）。
最終的に、どのような状況では、INTとしてPKをGUIDとして使用していますか？
GUIDをプライマリキーとして使用する場合、Kimberley Tripp（SQLSkills.com）はan articleです。彼女は不必要なオーバーヘッドのためにそれに対して反対します。
[このシリーズ]（http://sqlblogcasts.com/blogs/tonyrogerson/archive/2011/07.aspx）はまだ読んでいないが、私はTony RogersonがSSDで断片化の問題が大幅に軽減されていると主張していると思う。 –
INTは、デバッグ時にははるかに読みやすく、はるかに小さいです。
ただし、製品のライセンスキーとしてGUIDなどを使用します。あなたはそれが一意になることを知っています、そしてあなたはそれが逐次的ではないことを知っています。
プライマリキーと外部キーの関係などの値を比較すると、INTは高速になります。テーブルが適切に索引付けされていて、テーブルが小さい場合、スローダウンはほとんど見られないかもしれませんが、確かめるために試してみる必要があります。また、INTは読みやすく、他の人と通信するのが簡単です。 「レコード1234を見ることができますか？」と言うのはずっと簡単です。 「031E9502-E283-4F87-9049-CE0E5C76B658のレコードを見ることができますか？
その問題を軽減するために常にハッシュコードを使用してください。http：//hashids.org/ – Korayem
一部のOSは、ユーザーを簡単に追跡できるようにしたため（CPUID、MAC）、独自のハードウェア機能（CPUID、MAC）に基づいてGUIDを生成しません。つまり、GUIDの一意性は、多くの人が考えるほど普遍的なものではないことがよくあります。
データベースのいくつかの自動ID機能を使用する場合、データベースは理論上、重複がないことを絶対に確かめることができます。
これらの日は通常無作為に生成されます –
@Marcoこれを裏付けるドキュメンテーションへの参照はありますか？私はこれを聞いたことがない。 –
これはすでに古くからのニュースです。とりわけウィキペディアを参照してください。http://en.wikipedia.org/wiki/Globally_unique_identifier最も顕著なアルゴリズムセクション –
私はいつもPKが数字でなければならないと思っています。 PKはおそらく他のテーブルのforiegnキーとしても使用されているので、ページングやインデックスなどが大きくなるという意味でGUIDを持つことを忘れないでください。
レコードの自然キーが数値でない場合はどうなりますか？例えば（ホスト、タイムスタンプ）、製品レコードの（product_code）？あなたは冗長キーを持つ以外の目的を果たさない数値フィールドを追加することを主張しますか？ – bignose
いいえ、私はしませんが、タイムスタンプフィールドの場合は、IDフィールドをテーブルに追加し、タイムスタンプではなくキーとして使用することを検討できます。両方ともDBによって生成されるためです。 商品コードの場合は、あなたのビジネスに基づいて商品固有のIDとして常にそのIDを使用しますので、IDに変更する必要はありません。 これは、保存するデータの種類とデータベースの設計方法によって異なります。 – kevchadders
データベースも重要だと思います。 MySQLの観点からは、一般に、データ型が小さければ小さいほどパフォーマンスは速くなります。
あまりにもGUID対int型のためにも当てはまるようだ - http://kccoder.com/mysql/uuid-vs-int-insert-performance/
私は同様の値にのみ、このキー境界場合はPKとしてGUIDを使用します。たとえば、ユーザーID（WinNTのユーザーはGUIDで説明されています）またはユーザーグループIDです。 もう1つの例。あなたが文書管理のための分散システムを開発し、世界中のさまざまな場所でシステムの異なる部分を開発する場合、いくつかの文書を作成することができます。そのような場合は、分散システムの異なる部分で作成された2つのドキュメントが同じIDを持たないことを保証するため、GUIDを使用します。
あなたの質問に答えるには： 最終的に、どのような状況であなたはINTとしてPKをGUIDとして使用していますか？
システムにオンライン/オフラインバージョンがあり、オフラインバージョンの中にデータを保存することができ、そのデータが同期中の1日後にサーバーに戻される場合は、GUIDを使用します。そうすれば、データベース内で同じキーを2回使用することはないでしょう。
データが1つのデータベースに存在する場合（私たちが一般的に書いているアプリケーションのほとんどのデータがそうであるように）、私はIDENTITYを使用します。それは簡単で、そのように使用されることを意図しており、クラスタード・インデックスを断片化せず、それ以上のものです。 20億のレコード（負の値を使用する場合は40億〜）で部屋が使い果たされますが、1つのテーブルに多数のレコードがあり、データウェアハウジングの問題がある場合は、とにかくトーストになります。
データが複数の独立したデータベースまたはサードパーティサービスとのインターフェイスに存在する場合は、すでに生成されている可能性が高いGUIDを使用します。 Active DirectoryのユーザーをActive Directoryが割り当てられているobjectGUIDを介してアプリケーション内のユーザープロファイルにマップするデータベースのUserProfilesテーブルが良い例です。
INTは、スペースセーバー（この ポイントは、一般的に最も近代的な のシステムでは議論の余地がされているが）です。
そうではありません。一見したように見えるかもしれませんが、各テーブルの主キーは、インデックス内のデータベース全体にわたって、および他のテーブル内の外部キーとして複数回繰り返されることに注意してください。また、テーブルを含むほぼすべてのクエリに関与し、結合に使用される外部キーの場合は非常に集中します。
さらに、最新のCPUは非常に高速ですが、RAMの速度は維持されていないことに注意してください。したがって、キャッシュの動作はますます重要になります。そして、良いキャッシュ動作を得るための最良の方法は、より小さなデータセットを持つことです。したがって、4バイトと16バイトの間には一見無関係な違いが、速度の顕著な違いをもたらす可能性があります。必ずしもそうではありませんが、考慮すべきことです。
ある段階でデータベースをマージする予定の場合、つまりマルチサイトレプリケーションタイプのセットアップの場合、Guidは多くの苦痛を軽減します。しかしそれ以外に私はIntの方が簡単だと分かります。
複数のデータベースインスタンスを同期させる必要がある場合、INTの欠点は、私が見たことがない1つの欠点です。挿入は常にインデックスツリーの一方の端に発生します。これは、（同じインデックスページを同時に挿入することによって変更する必要があるため、GUIDはインデックス全体に挿入されるため）多くの動きのあるテーブルがある場合は、ロックの競合が増えます。 B *ツリーまたは同様のデータ構造が使用されている場合は、索引をより頻繁に再調整する必要があります。
もちろん、手作業によるクエリやレポートの作成時には、intの方が簡単であり、スペース消費はFKの使用によって増加する可能性があります。
私は、どれだけうまくいったかの測定値を見ることに興味があります。 SQL Serverは、実際にはIDENTITY PKを持つ重いテーブルを処理します。
非常に複雑なエンタープライズソフトウェアのどこにでもGuidsがあります。スムーズに動作します。
私はGuidsが意味的に識別子としての役割を果たすのに適していると信じています。あなたがその問題に直面するまでは、パフォーマンスについて不必要に心配する必要もありません。早すぎる最適化に注意してください。
また、任意の種類のデータベース移行で利点があります。ガイドでは衝突はありません。 intがIDとして使用されている複数のDBをマージしようとすると、それらの値を置き換える必要があります。これらの古い値がURLで使用されていた場合、SEOヒットに続いて異なる値になります。
エンタープライズソフトウェアのguidクラスタリングはどうですか？ – Koste
注：この質問は2009年に尋ねられました。http://softwareengineering.stackexchange.com/a/337560/156440およびhttp://stackoverflow.com/questions/11938044/what-are-the-best-キンバリー・トリップ（Kimberley Tripp）の最新のアドバイスへのリンクなど、より最新の回答を得るためのプラクティス・ベースの使い方として、主キー・レガ（primary-key-specific-rega） – HockeyJ