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 PKGUID 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 は本当にグローバルな識別子が 必要な場合にのみ利用すべきと言ってよさそうです。時間のあるときに今回のテスト方法等をまとめ、 このページを更新したいと思います。

関連書籍

このトピックに関するおすすめの参考資料は次です。

ここまでお読みいただき、誠にありがとうございます。SNS 等でこの記事をシェアしていただけますと、大変励みになります。どうぞよろしくお願いします。

© 2024 Web/DB プログラミング徹底解説