guidを主キーに、intを主キーとしてパフォーマンス比較を使います

クズども · 掲載地 2019/10/09 16:48:35

データベース設計では、guidやintをメインキーとして使うことが多いですが、これまでの知識に基づきintはメインキーとしてより効率的だと常に感じてきましたが、慎重なテストなしには不可能です

理由を説明してください。今日データベースの最適化中にこの問題に遭遇したので、テストを行いました。

試験環境:

デスクトップPC Pentiun(R) 4 CPU 3.06GHz
Win XP プロフェッショナル
1.5G DDRラム
SQL Server 2005 Personal

試験プロセス:

まずテストデータベースを作成し、テストします

ログインが見えます。

検査結果は以下の通りです。

前述の通り、intを主キーに使う場合、特に接続クエリやレコード削除がある場合、guidをメインキーに使う場合に効率が向上します。

さらに、現在のGUIDのメインキーを持つデータクエリでは、複数のサブクエリ結果の入れ子化によりクエリタイムアウトが繰り返し発生していました。したがって、私はintをメインキーにすることに賛成であり、guidをメインキーにするには賛成しません。
上記の見解は個人的な意見を表しており、誰でも意見を述べ、guidとintを主な鍵としての利点と欠点を説明してください。

フォローアップ検査:

兄弟の勧めを受けて、本日2つのサブテーブルにクラスタ化されていないインデックスが追加されました。

Test_Guid_Detail(Guid)で非クラスタインデックスIndex_Detail_Guidを作成する
Test_Int_Detail(ID)で非クラスタインデックスIndex_Detail_idを作成する
その後、内部接続クエリを行い、少霞@Xu氏が言ったように、効率は明らかに50%を超えず、基本的には約23%の改善程度で、それでも許容範囲内であることが分かりました。

したがって、推奨されます

1. データ移行が頻繁に行われるシステムでは、Guidの使用が推奨されます。また、対応する外部キーフィールド、すなわち結合クエリに使われるフィールドにクラスタ化されていないインデックスを追加することは、パフォーマンス向上に大きな利点をもたらします。ここで条件のフィールドは、クラスタリングされていないインデックスにも適宜追加できます。

2. Guid型を主キーとして使用する場合、データ型はuniqueIdentifierであるべきであり、プライマリキーの「集計インデックス」はキャンセルすることを忘れないでください

3. 移行不要なシステムや小規模なシステムでは、intを主キーとして使用することが非常に便利であり、効率の向上も一定の見方があります。

クズども · 掲載地 2021/02/08 11:03:12

試験

クズども · 掲載地 2021/02/08 11:03:31

ジャンリー · 掲載地 2025/03/20 16:13:51

intプライマリキーの移行は大きな問題ではありません。移行中にintプライマリキーが一時的にキャンセルされ、その後に自己増分が開かれれば問題ありません

[出典] guidを主キーに、intを主キーとしてパフォーマンス比較を使います

関連記事

閲覧したセクション