UUID 產生器

什麼是 UUID？為什麼需要它？

UUID (Universally Unique Identifier)，中文稱為「通用唯一識別碼」。它是一串 128 位元的數字，通常以 32 個十六進位數字顯示（例如 550e8400-e29b-41d4-a716-446655440000）。

在傳統的資料庫設計中，我們習慣使用「自動遞增 (Auto Increment)」的整數作為 ID (如 1, 2, 3...)。但在分散式系統或微服務架構中，這種依賴單一資料庫發號的方式會成為瓶頸。UUID 的出現解決了這個問題：它讓每一台機器都能獨立產生 ID，且保證**「全球唯一，絕不重複」**。

核心原理：天文數字般的機率

UUID 的核心精神是「由空間換取唯一性」。

• UUID 的總數量高達 $2^{128}$ (約 $3.4 \times 10^{38}$)。

• 這個數字大到超乎想像。就算您每秒產生 10 億個 UUID，持續產生 100 年，發生重複 (碰撞) 的機率仍然比「被隕石擊中」還要低。

• 因此，我們可以放心地在不同伺服器上產生 UUID 並合併資料，完全不用擔心 ID 衝突。

常見版本比較：v1 vs v4

雖然 UUID 有五個版本，但最常用的是 v1 和 v4。

UUID v1 (時間與網卡位址)

• 原理： 根據當前的「時間戳記」加上機器的「MAC 位址」生成。

• 優點： 具有時間順序性 (可排序)。

• 缺點： 因為包含 MAC 位址，可能會洩漏伺服器的硬體資訊 (隱私問題)。

UUID v4 (完全隨機) —— 本工具預設

• 原理： 使用亂數產生器 (RNG) 生成，其中只有少數位元用來標示版本，其餘全部隨機。

• 優點： 隱私性極佳，實作簡單，是目前 Web 開發與資料庫主鍵的主流標準。

• 缺點： 完全無序，對某些舊式資料庫的索引效能可能有輕微影響。

常見的應用場景

1. 資料庫主鍵 (Primary Keys)

這是最常見的用途。使用 UUID 作為 Primary Key，可以避免被競爭對手猜出您的資料量（例如：如果訂單 ID 是 1001，下一筆是 1002，對手就能知道您一天有多少訂單）。

2. Session ID 與 Token

在 Web 應用中，用來標記使用者的登入狀態或交易階段。由於 UUID v4 是不可預測的，駭客無法透過猜測 ID 來偽造身分。

3. 分散式系統與資料合併

如果您有多個分店的資料庫需要彙整到總部。如果使用傳統 ID (1, 2, 3)，各分店的 ID 會重複衝突；使用 UUID 則可以直接合併，無需重新編號。

常見問題 (People Also Ask)

Q1：UUID 和 GUID 有什麼不同？

完全一樣。

• UUID： 是標準組織 (IETF) 使用的術語，Linux/Unix 圈子常用。

• GUID (Globally Unique Identifier)： 是微軟 (Microsoft) 使用的術語。

• 本質上它們指的都是同一個 RFC 4122 標準的東西。

Q2：UUID 真的「絕對」不會重複嗎？

理論上會，但實務上「不可能」。

• 雖然它是隨機產生的，數學上存在碰撞的可能性。

• 但那個機率低到在人類文明存續期間幾乎不可能發生。所以在工程實務上，我們將其視為「絕對唯一」。

Q3：為什麼有些 UUID 沒有連字號 (Hyphens)？

只是格式不同。

• 標準格式：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (36 字元)。

• 緊湊格式：xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (32 字元)。

• 兩者代表的數值是一樣的。本工具提供選項讓您移除連字號，方便存入資料庫。

Q4：UUID 會影響資料庫效能嗎？

稍微會。

• 因為 UUID (128-bit) 比傳統整數 (32/64-bit) 佔用更多空間。

• 且 UUID v4 是無序的，可能會導致資料庫索引 (B-Tree) 頻繁重組 (Fragmentation)。

• 解法： 現代資料庫 (如 PostgreSQL) 對 UUID 有專門優化；或者您可以考慮使用「UUID v7 (基於時間排序)」來改善寫入效能。