GUID (uniqueidentifier) と INT IDENTITY
はじめに
データベースのキーとして INT IDENTITY を使わずに、やたらと GUID (Uniqueidentifier) を使いたい人が いるようなので、その動作確認をしました。これはそのメモ書きです。
実験結果
先に "実験結果" を書くと、 GUID 及び INT IDENTITY 両方をキーに設定しない(インデックスを作らない)場合のみ、データの INSERT に GUID が僅かに速いように見られましたが (測定誤差か何か微妙な位)、その他の場合はほぼ差がないか、 全ての場合において、INT IDENTITY の方が INSERT, SELECT 共に速いことが測定されました。 正直なところ、片手間にテストしており、単純なクエリしか試していないので、これで 双方に差がないと結論付けできるとも思えませんが、ともあれ現時点では明快な差は計測していません。 (正直なところ、複雑なクエリではきっと大きな差が出るだろうという予想(?)は持ち続けていますが、 現状はそれを確認するに至っていません)
ただ一点、顕著に問題となると思われたのは、GUID を Primary Key とした場合 (すなわち CLUSTERED INDEX となる場合) に、INSERT がデータ件数の増加に伴い顕著に遅くなったことです。
データを 3 万件挿入した場合に要した時間は以下の表のようになりました。
データ件数 | INT IDENTITY PK | GUID PK |
最初の30,000件 | 39秒 | 48秒 |
次の30,000件 | 37秒 | 1分16秒 |
次の30,000件 | 38秒 | 1分36秒 |
次の30,000件 | 37秒 | 1分51秒 |
次の30,000件 | 38秒 | 2分6秒 |
INT IDENTITY をキーにした場合は、全体のデータ件数が増えても安定して 38秒程度で処理を終えているのに対して、 GUID をキーにした場合は、全体のデータ件数が増加するに伴って、処理時間が増加することがわかります。 高々数万件で、これだけ顕著に遅くなる (しかも単純な INSERT で) ので、設計の際にはこの問題には注意を払うべきと思われます。
まとめ
以上簡単な動作確認で、今回は (時間と手間の都合で) 実行時間のみを確認しましたが、明らかにデータサイズは 大きいですし上記に挙げたはっきりした問題があるので、GUID は本当にグローバルな識別子が 必要な場合にのみ利用すべきと言ってよさそうです。時間のあるときに今回のテスト方法等をまとめ、 このページを更新したいと思います。
関連書籍
このトピックに関するおすすめの参考資料は次です。