最も効率的なUUID列タイプは何ですか

128ビットUUIDを保存するには、複数の保存オプションがあります。

1. byte [16]列
2. 2つのbigint / long（64ビット）列
3. CHAR（36）列-32桁の16進数+ 4つのダッシュ。
4. dbがサポートしている場合、UUIDデータベース固有の列

インデックスの観点から、どれが最も効率的ですか？データベースが専用のuuidタイプをサポートしていない場合、1、2、3のうちどれが最適な候補ですか？

uuidPostgreSQLには、専用タイプが最善の策です。他のDBでは言いにくい- uuid単純なバイト型よりも効率的に格納されていない型を暗示することは不可能ではありません。

再びPostgreSQLではbytea、uuid型がない場合にUUIDを格納するのに合理的な方法です。他のDBの場合、バイナリデータの保存方法に依存します。

可能であれば、hex-with-dashesの使用を強く避けます。比較、ソート、保存を行うのは効率的ではありません。

本当に、「（2）または（3）ではない」。今まで。サポートされている場合は（4）、それ以外の場合は（1）を使用します。

優先順位：4,1,2,3 SQLサーバーを使用する場合、UUIDをクラスタリングキーとして使用しない各インデックス行。断片化はNEWSEQUENTIALIDを使用して軽減できますが、通常は他のインデックスの膨張を防ぐために、GUIDよりもクラスタリングキーのbingint IDを優先します。

1から2を選択する場合の違いは、単一列固定配列よりもデータベースが基本型の2列をより効率的に処理できるかどうかに依存します。ダミーデータでテストするのに十分簡単なはずです。クエリの速度と、インデックスとデータのサイズを確認してください。Small + fastが最適です！

ネイティブにサポートされているデータ型は、その製品のクライアントとしてまとめることができるものよりも、製品で最適化されると想定する必要があります。その後、バイトカウントが最も小さいものであれば、ページごとに最大行を取得します。