UUID ジェネレーター: V1、V4、V7 の説明 (そして実際に使用するもの)

初めてUUIDが本当に私にとって重要だったのは、私はWordPressに隣接するSaaSを単一のMySQLボックスから読み取りレプリカを備えたセットアップに移し、後でシャードにする計画でした 自動増分IDは何年も問題ありませんでした - 2 つのサービスが同じ論理テーブルになるものに挿入し始めるまで、そして突然 id = 42 2つの異なる行を意味しました。 自動インクリメントが静かに機能しなくなる瞬間であり、UUID が通常の答えです。

UUID は、どのマシンでも、調整なしでいつでも生成できる 128 ビット値です。信頼は、一意であると信頼されます。 「調整なし」という部分が要点です。機内でオフラインのモバイル アプリ、3 つのマイクロサービス、バックグラウンド ワーカーは、すべて同時に ID を作成して衝突することはありません。 自信を裏付ける数学は本当にばかげています。私はすぐにどれほどばかげているかをお見せします。

ザ・ uuid ジェネレーター on Toolz.dev creates single or bulk UUIDs in multiple versions in murthen, right in your browser - handy when you're seeding a table or need a throwaway ID for a test.このガイドでは、バージョンが実際に何を意味するのか、2026 年にどれを選ぶか、データベースインデックスを破壊せずに保存する方法、そしてそれらをスキップできるように私が犯した間違いについて説明します。

tl;dr: 2026 年の新しいデータベースの主キーの場合、生成 uuid v7ー it' s time-ordered so it indexes well, and it does' t leak hardware like v1. (訳注: 39; は時間順に並べられているのでインデックスがうまくでき、v1 のようなハードウェアを使う v4 純粋な予測不可能性が欲しいとき。 それらをネイティブとして保存します uuid タイプまたは BINARY(16)、決して VARCHAR(36)。 でまとめて作る uuid ジェネレーターと、それをペアリングします。 タイムスタンプ コンバーター V7 に焼き付けた時間を読み取る。 すべてのクライアント側、すべて無料。

UUID とは正確には何ですか?

UUID (Universally Unique Identifier) とは、中央機関がIDを配ることなく、何かを識別するために使用される128 ビットの番号です。 Microsoftは同じものをGUID (Globally Unique Identifier) と呼びます; they' 重要なすべての点で同一です。 canonical text form is 36 characters - 32 hex digits split into five hyphenated groups of 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

それらの 16 進位置のうち 2 つは aren't ランダム データ - they're メタデータです。 13 番目の 16 進数はエンコードされます バージョン (どの世代戦略がそれを作ったのですか) であり、4 番目のグループの最初の桁が 変種 (どのレイアウト標準に従うか) - 8、 9、 a、または b 標準の UUID の場合)。 上の例では、 4 3 番目のグループでは、それが v4 だと言っています。

「ユニーク」は本当にユニークなの?

バージョンとバリアント ビットが予約された後、V4 UUID には 122 のランダム ビットがあります。 2^122 の可能な値、つまり約 5.3 アンデシリオン:

5,316,911,983,139,663,491,615,228,241,121,400,000

具体的にするために: 毎秒 10 億 UUID を生成した場合、50% の確率で 100% の確率で達成するまでに、約 86 年かかる必要があります。 独身 どこでも衝突。 実際のエンジニアリング用語では、V4 の衝突は発生せず、決して起こらないかのように設計できます。

UUID v1、v4、および v7 の違いは何ですか?

仕様 - もともと RFC 4122、現在によって更新されています RFC 9562 (2024)ーはいくつかのバージョンを定義します。 3 つは日々の仕事に重要です。

UUID v1 - タイムスタンプ + MAC アドレス

v1 は、ネットワーク カード & #39;s MAC アドレスを使用して、100 ナノ秒のタイムスタンプ (グレゴリオ暦が始まった日である 1582 年 10 月 15 日からカウントされます。スペック トリビアの私のお気に入りの 1 つ) をつなぎ合わせます。 It's は自然に時間順に並べられており、そこから作成時間を抽出できます。

問題は定義にあります。それを作成したマシンの MAC アドレスを埋め込みます。 これにより、ハードウェアのアイデンティティがリークし、タイムスタンプと組み合わせると、ID がある程度予測可能になります。 例: 6ba7b810-9dad-11d1-80b4-00c04fd430c8。 現在、レガシー互換性のために v1 のみを使用します。

UUID v4 - ランダム

V4 は 122 ビットのランダム性であり、他には何もありません。 これは、ほとんどの人が「UUID」と言うときに意味するバージョンです。そして、それは非常に単純です。タイムスタンプもハードウェアも注文もありません。 例: f47ac10b-58cc-4372-a567-0e02b2c3d479。

利点は、何も漏れず、予測不可能であるということです。これは、推測できないものにまさに求めていることです。 マイナス面は、 ランダム、従って連続した挿入はあなたの索引のすべてに散らばる - 私が知ったように、それはスケールで実質性能費用がある。

UUID v7 - 時間順 + ランダム

V7 は、RFC 9562 で標準化された現代的な妥協案です。 最初の 48 ビットは、ミリ秒単位の UNIX タイムスタンプであり、残りはランダムです。 例: 018e4880-d4d0-7b9c-8c37-2a5c0f1e3d8a。

そのレイアウトは、v7 IDが時系列に並べ替えることを意味します - 新しい行は散乱ではなく、Bツリーインデックスの"end"に着地します - グローバルに一意であり、調整が不要でありながら、おおよその作成時間 (通常は問題ありません) を漏らしますが、ハードウェアは漏らしません。新しいプロジェクトの場合、これは私のデフォルトの主キーであり、it'sはIETFが指す方向でもあります。

一目でトレードオフを次に示します。

あまり使用されていないバージョンも存在します。v3 と v5 は名前空間の決定論的ハッシュと名前 (v5 は SHA-1 を使用し、V3'S MD5 よりも優先されます) であり、V6 は再注文された v1 であり、v8 はカスタム実装用に予約されています。

UUID または自動インクリメント ID を使用する必要がありますか?

これは、他のどのデザイン レビューよりも多くのデザイン レビューで私が行った議論です。これが、私が実際に使用するフレームワークであり、宗教的な答えではありません。

自動インクリメントを続ける あなたは、単一のデータベースを持っています, パフォーマンスとストレージはタイトです, そして、人間は、IDを読み取る必要があります. 整数は、4 ~ 8 バイト対UUID& #39; s 16, 整数の比較は、より高速です, と " order #12345" は、はるかに簡単に36 文字のUUIDよりも電話を読み下げます. shardingのない単一のボックス上で, 自動インクリメントは、本当にシンプルで高速な選択です - don& #39; 流行遅れのUUIDのためのリーチ.

UUID に切り替えるとき これらのいずれかが本当です: you& #39; 再配布 (複数のサービスまたはサーバーが独立してIDを鋳造) 、 you& #39; 列挙について心配しています (自動増分IDは推測可能であり、静かにレコードカウントを明らかにします -) /users/1234 攻撃者に、ユーザーが 1,235 人未満であると伝えます)、複数のデータベースからのデータを衝突なしでマージする必要があるか、クライアントが同期する前に ID を生成する必要があることを伝えます。 その列挙点は、人々の評価を過小評価するセキュリティ上の考慮事項です。

そして V7 の中間点: uuid v7 は、uuid の分散型世代を提供します あんど レコード数を漏洩することなく、自動インクリメントのインデックス フレンドリーな順序付け。 2026 年のほとんどの新しいプロジェクトでは、非順次 ID が必要な場合、V7 が議論を終わらせる答えです。

インデックスを壊さずに UUID を保存するにはどうすればよいですか?

これは、私自身の高額なミスから生まれたセクションです。他のどこにもない場合は、ここに注意してください。

私が言及した移行で、新しい UUID を次のように保存しました。 VARCHAR(36) 明らかで読みやすいことだったからです うまくいきました - そしてテーブルが大きくなり 挿入と結合が測定可能なほど遅くなりました 2 つの問題がさらに悪化しました 1IDあたり16 バイトではなく 36 バイトを費やしていました あんど 私はランダムな V4 UUID を使用していたので、すべての挿入物が主キー インデックスのランダムな場所に着陸し、それを断片化してバッファー プールをスラッシングしました。 修正はバイナリとして保存され、次のプロジェクトでは V7 に切り替えて、挿入は連続したままでした。

PostgreSQL ネイティブがいる uuid type - use it. 16 バイトを格納し、高速で比較します:

CREATE EXTENSION IF NOT EXISTS "pgcrypto";

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

mysql ネイティブ UUID タイプがないので、保存してください BINARY(16) そして変換して UUID_TO_BIN() / BIN_TO_UUID()。 2 番目の引数は重要です。

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- The `true` swaps the timestamp bytes for better index locality on v1
INSERT INTO users (id, name, email)
VALUES (UUID_TO_BIN(UUID(), true), 'Alice', '[email protected]');

SELECT BIN_TO_UUID(id, true) AS id, name, email FROM users;

覚えておくべきルール: ネイティブ uuid あるところにタイプして、 BINARY(16) あなたが知らないところ、そして VARCHAR(36) 基本的に、あなたがインデックスを付けて参加するキーの場合は決してありません。

コードで UUID を生成する方法を教えてください。

簡単な1回限り、 uuid ジェネレーター repl を開くよりも速いです。 コードでは、すべての主要言語に組み込まれているか、一歩先を行くことができます。

JavaScript / Typesc- ブラウザとノードは両方とも v4 ジェネレータを出荷します:

const id = crypto.randomUUID();   // v4, no dependency needed
// For v7, use the 'uuid' package:
import { v7 as uuidv7 } from 'uuid';
const ordered = uuidv7();

パイソン:

import uuid
uuid.uuid4()                                  # random
uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com') # deterministic (SHA-1)

ジャワ: UUID.randomUUID() V4 は箱から出してすぐに使える; v7 には次のようなライブラリが必要です java-uuid-generator または、小さな RFC 9562 実装。

行く: github.com/google/uuid あなた両方を与える - uuid.New() v4 と uuid.NewV7() v7 用。

ネイティブ ランタイム ヘルパーは、ほとんどの場合、v4 を提供することに注意してください。 具体的に V7 の順序付けが必要な場合は、ライブラリが新しい標準であり、すべての stdlib が追いついたわけではないため、通常はライブラリが必要です。

UUID は実際に実際のシステムでどこに表示されますか?

UUID については、アブストラクトで簡単に話すことができます。そのため、私が頼った具体的な場所を次に示します。これは、選択したバージョンは実際に仕事に依存するためです。

分散セットアップのデータベース主キー。 これは古典的なケースであり、私のためにこの記事を始めたものです。複数のライターが同じ論理テーブルに挿入できる瞬間 - レプリカ、シャード、またはスキーマを共有する 2 つのサービス - 自動増分が壊れます。 v7 主キーは調整の問題を解決しますが、それでも完全にインデックスを付けます。 it's は時間順に並べられています。

オフライン ファースト アプリのクライアント生成 ID。 モバイルアプリやブラウザSPAは、多くの場合、それがサーバと話すことができる前にレコードを作成する必要があります - 飛行機に書かれたメモを考えて、または即座に新しい行を表示する楽観的なUIを考えて、クライアントがUUIDを前面にミントした場合、レコードは、最初のキーストロークから安定したアイデンティティを持ち、" へのサーバ往復なしで後で同期しますIDを取得します." I& #39; これを使用して、フォームが薄片状の接続でも瞬時に感じられるようにしました。

URL と API の列挙できないリソース識別子。 パッティング /orders/1042 URL で、あなたがせいぜい 1,042 件の注文を受けたことを誰かに伝え、彼らに歩かせてください /orders/1041、 /orders/1040、など.UUID でスワップすると、ビジネス メトリクスのリークと簡単な列挙の両方が削除されます。 URL でユーザーが見ることができるものは何でも、これは実行する価値があります。ただし、UUID はアクセス制御メカニズムではないことに注意してください。;その背後には実際の承認チェックが必要です。

トレースの相関 ID。 単一のリクエストが 5 つのマイクロサービスにわたって展開され、相関 ID として 1 つの UUID を添付し、ホップごとにそれを記録すると、" この混乱のどこかで何かが失敗し、quot; がすべてのログにまたがる単一のグレップ可能な文字列に記録されます。これは、プレーンな v4 でさえ完璧である 1 つの場所です。これは、順序付けを必要とせず、一意性だけです。

等身キー。 Payment と Webhook API は、再試行されたリクエストがカードに 2 回請求しないように、UUID を等期キーとして送信するようクライアントに要求することがよくあります。 クライアントは一度生成して再試行し、サーバーはそれを重複排除します。 これは、非常に高価なクラスのバグを防ぐ小さなパターンです。

よくある質問

UUID は何に使用されますか?

UUID は、ID を配布するための中央サービスを必要とせずに、データベース行、API リソース、セッション、アップロードされたファイル、マイクロサービス間のトレースなど、何かを一意に識別します。 It'複数のシステムまたはクライアントが独立して識別子を作成する必要がある場合でも、確実に識別子を作成して #39;t が衝突する場合に、すぐに識別子を生成できます uuid ジェネレーター Toolz.dev で。

2 つの UUID が同一になることはありますか?

理論上はい、実際にはいいえ。 V4 UUID には 122 個のランダム ビットがあり、約 5.3 の無減数の可能性があります。 1 回の衝突の確率で 50% に達する前に、2.7 5 兆 UUID 程度で生成する必要があります。 あらゆる実際のエンジニアリング目的で、UUID を一意に保証するものとして扱うことができます。

2026 年に使用すべき UUID バージョンはどれですか?

新しいデータベースの主キーの場合、UUID v7 - it's はグローバルに一意性を維持しながら効率的なインデックス作成を行うために時間順に並べられており、it's は RFC 9562 に基づく現在の IETF 推奨事項です。 v4 は、推測できない識別子など、予測不可能性が重要な場合に使用します。 v1 は、生成マシン's MAC アドレスを埋め込むため、新しい作業には避けてください。

UUID は順番ですか?

v1 と v7 は時間順序付けされているため、後で生成された ID は以前の ID の後に並べ替えられます。 v4 は順序なしで完全にランダムです。 v7 を B ツリー インデックスに優しいものにしているのは、順序付けです。新しい行は散乱ではなく追加されます。 ' が大きなテーブルの主キーとしてランダム v4 を使用している場合、順序の欠如により挿入とインデックスのパフォーマンスが低下する可能性があります。

UUID をデータベースに保存するにはどうすればよいですか?

ネイティブを使う uuid データベースが 1 つある場合は入力します (PostgreSQL にあります)。 それ以外の場合は保管 BINARY(16)、および MySQL 8.0 以降で変換 UUID_TO_BIN() あんど BIN_TO_UUID()。 避ける VARCHAR(36) や CHAR(36) キーの場合、文字列ストレージは行あたり 20 バイトを無駄にし、すべての比較を遅くするため、大きなテーブルでは高速に加算されます。

UUID と GUID の違いは何ですか?

それらは同じものです。 UUID は、ほとんどの言語とプラットフォームで使用される RFC 4122 の用語で、GUID は Microsoft の名前で、Windows と .NET で一般的です。 形式と保証は同じであるため、GUID と UUID を同じ意味で扱うことができます。

UUID から作成時間を抽出できますか?

v1、v6、および v7 から、はい、タイムスタンプをエンコードします。 v7 は最初の 48 ビットにミリ秒の Unix タイムスタンプを保存し、デコードして読み取ることができます タイムスタンプ コンバーター。 V4 と V5 には時間情報が含まれていないため、そこから抽出するものは何もありません。

UUID v4 は、セッション トークンに対して十分に安全ですか?

それ自体ではありません。 V4 の 122 のランダム ビットは予測できませんが、通常、セッションおよび認証トークンは、暗号化されたセキュアなジェネレーターから少なくとも 256 ビットを必要とします。 認証用に専用のセキュア ランダム トークンを使用し、リソースを保護するのではなく、リソースを特定するために UUID を予約します。

UUID を生成するにはどうすればよいですか?

言語の組み込みジェネレータを使用してください。 crypto.randomUUID() 最新のブラウザと Node.js では、 uuid.uuid4() Python で、または Guid.NewGuid() .NET では、それぞれが 1 回の通話で V4 UUID を生成します。 1 回限りまたはバッチで簡単に作成できます。 uuid ジェネレーター on Toolz.dev - コードは必要ありません.

UUID は何文字ですか?

UUID は、正規のテキスト形式で 36 文字です。32 個の 16 進数と、8-4-4-4-12 グループに分割された 4 つのハイフン。 そのテキストは 128 ビットをエンコードするため、16 バイトとして格納します。 BINARY(16) 36 文字の文字列よりもはるかにコンパクトです。

まとめ

UUID は、あなたが行う基盤の 1 つです & #39; システムが単一のデータベースを超えて成長するまで考えないでください - そして、それら & #39;すべてです。 2026 年のショート バージョン: デフォルト v7 新しい主キーの場合は、 v4 推測できない ID が必要な場合は、次のように保存します。 ネイティブ uuid や BINARY(16)、および新しいものについては v1 をスキップします。 私から学ぶ VARCHAR(36) 午後だから繰り返さないでください。

無料で即座に生成 uuid ジェネレーター on Toolz.dev - single or bulk, any version, all client-side with nothing uploaded. v7 の中の時刻を読む必要があるときは、 に手を伸ばす タイムスタンプ コンバーター、そして残りの部分を参照してください コーディング ツール- 600+ 無料ユーティリティ - でオーバー Toolz.dev。