UUID v7ジェネレーター｜最新規格UUID

UUID v7は以下のフィールドで構成されます。unix_ts_ms（48ビット）は生成時のUnixタイムスタンプ（ミリ秒精度）、ver（4ビット）はバージョン番号（0111 = 7）、rand_a（12ビット）はランダムビット、var（2ビット）はバリアントビット（10）、rand_b（62ビット）はランダムビットです。タイムスタンプが先頭に配置されているため、辞書順ソートと時系列順が一致します。

UUID v4（ランダム）をプライマリキーに使うと、新しいレコードがインデックスの任意の位置に挿入されるためB-treeページの分割が頻繁に発生し、インデックスの断片化・キャッシュミスが増加します。UUID v7はタイムスタンプベースの単調増加のため、新しいレコードは常にインデックスの末尾に追加されます。これはAUTO_INCREMENTやSERIALと同様の挿入パターンで、大規模テーブルでのINSERTパフォーマンスを大幅に改善します。

UUID v7はRFC 9562（2024年）で標準化されたばかりの新しい仕様ですが、主要な言語・フレームワークで急速にサポートが広がっています。PostgreSQLではpg_uuidv7拡張が利用可能で、将来のバージョンでのネイティブサポートが議論されています。Laravel（PHP）ではStr::uuid7()として実装済みです。Node.jsではuuidライブラリのv7対応版が利用可能です。Rustのuuidクレートもv7に対応しています。

PostgreSQLではUUIDをUUID型カラムとして定義できます。UUID v7はRFC 9562準拠の標準UUID形式なので既存のUUID型カラムにそのまま格納可能です。インデックスのパフォーマンスを最大化するには、主キーカラムをUUID型にしてUUID v7を挿入します。PostgreSQL 14以降ではGEN_RANDOM_UUID()（v4生成）の代わりにアプリケーション側でv7を生成して渡す形が推奨されます。将来的にはpostgresql/uuidv7拡張でデータベース側生成も可能です。

MySQL 8.0以降のUUID_TO_BIN()・BIN_TO_UUID()関数はUUID v4を前提にしていますが、UUID v7の値も同様に格納できます。BINARY(16)型での格納が最も効率的です。MySQLのUUID()関数はv1を生成しますが、アプリケーション側でUUID v7を生成してBINARY(16)カラムに格納することでINSERTパフォーマンスを改善できます。インデックスの断片化を防ぐためには、文字列としてのVARCHAR(36)格納よりBINARY(16)が推奨されます。

UUID v7にはミリ秒精度のタイムスタンプが含まれるため、IDを公開する場合はレコードの作成時刻が推測される可能性があります。これはUUID v1と同様の考慮事項です。ユーザーIDや機密リソースのIDとして外部公開する場合は、タイムスタンプ情報を含まないUUID v4の使用を検討してください。内部システムIDやデータベースの内部キーとして使用し、APIレスポンスには別のID（v4等）を返す設計も有効なアプローチです。