通常、int。
bigintは、宇宙にある原子よりも多くの行があると思われる場合。
uniqueidentifierは、必要な場合に便利ですグローバル一意のキー（スキーマ内のすべてのテーブルで一意であることが保証されているキー。
私が使用しない他の2つは整数型ではありません（それらは分数を持っていますが、キーとしてはあまり意味がありません）
次の2つの問題を区別する必要があります。
1）主キーは論理構造です。テーブル内の行を一意かつ確実に識別するキー候補の1つです。これは本当に何でも構いません-INT、GUID、文字列-あなたのシナリオにとって最も意味のあるものを選んでください。
2）クラスタリングキー（テーブルの「クラスター化インデックス」を定義する列）-これは物理ストレージ関連のものであり、ここでは小さい、安定した増え続けるデータ型が最良の選択です-デフォルトオプションとしてINTまたはBIGINT。
既定では、SQL Serverテーブルの主キーはクラスタリングキーとしても使用されますが、そのようにする必要はありません！個人的には、以前のGUIDベースのプライマリクラスター化キーを2つの個別のキーに分割すると、時間の経過とともにパフォーマンスが大幅に向上するようです。GUIDのプライマリ（論理）キーと、個別のINT IDENTITY（1 、1）列。
インデックスの断片化が最小限のレベルに低下したため、インデックスシークのパフォーマンスが向上しました-強くお勧めします！
マーク
PKにGUIDを使用しない大きな理由の1つは、インデックスページの塗りつぶし率がひどいことです。このような誤用は、I/Oパフォーマンスコストを劇的に増加させる可能性があります。 GUIDはAKのままにして、代わりにintから派生したPKで可能な限りクエリを実行する必要があります。
32ビットプロセッサの場合、intが処理に最も効率的なサイズになる可能性があります。
GUID/UUIDは、テーブルの一意の主キーに最適なフィールドタイプです。
unsigned int特定のニーズを満たすサイズ