ULID 生成器

ULID 是什麼

ULID 是一個 128 位識別符號，寬度與 UUID 相同，分為兩部分：48 位毫秒時間戳，後接 80 位隨機資料。它以 26 個字元的 Crockford base32 表示，而不是 UUID 那種帶連字元的 36 字元十六進位制，因此更短、大小寫不敏感，並且剔除了最容易看錯的字元——字母表中不含 I、L、O 和 U。

真正關鍵的差異不在編碼，而在排序。由於時間戳佔據高位，而 base32 保持位元組序，把 ULID 當作普通字串排序，結果就是按建立時間排序。同一毫秒內生成的兩個 ID 會退化為比較隨機部分，但跨毫秒的順序是精確的。

可排序性對資料庫為什麼重要

UUIDv4 是均勻隨機的，而這恰恰是聚簇索引最不需要的性質。每次插入都落在 B 樹的隨機位置，資料庫因此不斷分裂頁面並觸碰冷頁。索引膨脹到超出必要的體積，寫入吞吐也隨表增長而劣化。這是 MySQL InnoDB 和 SQL Server 中 UUID 主鍵眾所周知的問題。

按時間有序的識別符號會追加在索引的右端附近，訪問模式與自增整數一致。你既保留了客戶端生成全域性唯一鍵的好處——無需往返取 ID、服務之間無需協調、跨分片合併安全——又避開了索引碎片化。

什麼時候該換別的方案

RFC 9562 標準化的 UUIDv7 用標準 UUID 的格式和佈局實現了與 ULID 相同的效果。如果你的技術棧已經具備原生 UUID 列型別和配套工具，如今通常應優先選 UUIDv7，理由很簡單：它能直接融入既有生態。而當你希望在 URL 或日誌中使用更短、更友好的文本形式時，ULID 依然有吸引力。

無論選哪種，都要清楚時間戳對任何持有該 ID 的人都是可見的。建立時間會洩露，相鄰 ID 會暴露先後順序——凡是列舉關係或時間資訊敏感的場景都不要使用。另外，每毫秒 80 位隨機數意味著碰撞在實踐中不必擔心，但 ULID 並不是秘密，絕不能當作訪問憑證使用。