UUID 產生器

該用 v4 還是 v7

v4 UUID 是 122 個隨機位元。v7 UUID 把開頭 48 個位元換成 Unix 毫秒時間戳，其餘仍是隨機值。兩者都是 128 位元、都寫成 36 個字元，實務上都不會重複。差別在於順序。

v4  9f8b3c12-5d4e-4a7b-8c19-2f6e0a5b7d31
v7  0198c4a1-7e2f-7c33-b8d0-5a1c9e7f2b64
     └──── 自 1970 年起的毫秒數 ────┘

把一串 v7 UUID 當字串排序，順序就是產生的先後；v4 排出來則是一團雜訊。

這對資料庫為什麼重要

多數關聯式資料庫會以主鍵建立 B-tree 來存放資料表。以隨機順序寫入代表每一筆都落在不同的頁面： 工作集從索引的尾端變成整個索引，頁面分裂大量增加，寫入吞吐量會隨著資料表變大而下降。以大致遞增 的順序寫入，則只會一直附加在同一個熱頁面上。

這就是 MySQL 長年建議不要用隨機 UUID 當主鍵的原因，也是 v7 被標準化的原因——它在 2024 年 5 月 隨 RFC 9562 定案，同時納入 v6 與 v8，取代了 RFC 4122。

要寫進有索引的欄位、而且讓人看出大概的建立時間也無妨的資料，選 v7。若識別碼會公開露出、且不能 洩漏任何資訊，選 v4：拿到一個 v7 值的人，可以精確到毫秒推知那筆資料是什麼時候建立的。

版本與變體的位置

規格固定了兩個位置，它們不是隨機的：

• 第 13 個十六進位字元是版本，上面的例子分別是 4 與 7。
• 第 17 個十六進位字元是變體，會是 8、9、a 或 b 其中之一。

所以 v4 UUID 實際只有 122 個自由位元，而不是 128 個。這仍然足夠讓碰撞不成為實際問題——大致要 每秒產生十億個、持續數十年，才會開始需要擔心。

在程式中產生

crypto.randomUUID()                       // v4，瀏覽器與 Node 19 以上

SELECT gen_random_uuid();                 -- PostgreSQL 13 以上，v4

import uuid; uuid.uuid4()

v7 目前在多數標準函式庫還沒有內建；PostgreSQL 從 18 版起提供 uuidv7()。在那之前得靠套件，或是 自己寫幾行把時間戳填進前六個位元組。

你的資料只留在這裡

這些值由瀏覽器的 crypto.getRandomValues 產生，那是平台提供的密碼學安全亂數來源。沒有任何值在 伺服器上產生，也沒有任何紀錄，所以你從這個頁面取走的 UUID 只有你自己的電腦看過。