P7領導建議：可以用UUIDv7作為數據庫主鍵

作者：田螺 2025-06-04 02:15:00

數據庫其他數據庫

我們提到分布式主鍵ID的時候，可能都會想到UUID，比如在設計數據庫主鍵的時候。但是可能最終都不會考慮它。但是呢，最近領導卻建議說，可以考慮它作為數據庫主鍵了，因為UUIDv7的出現~~

前言

大家好，我是田螺。

1. 傳統 UUID 作為主鍵的缺點

傳統 UUID（尤其是 v4）的完全隨機性是其作為數據庫主鍵的“原罪”：

無序性 (最主要問題):

數據庫索引（尤其是 B+Tree）依賴主鍵順序插入新記錄效率最高。
UUID 隨機生成，插入位置不確定，導致索引樹頻繁分裂和重組，大幅降低寫入性能。
破壞聚簇索引（如 InnoDB）的物理存儲順序，增加磁盤 I/O。
范圍查詢和排序效率低下，性能低下。

存儲空間大：

占用存儲空間是自增整數（如 64位 BigInt）的 2倍。
導致索引更大，占用更多內存/磁盤，緩存效率降低，查詢變慢

2. UUIDv7 的核心突破：時間有序性架構設計

UUIDv7 的革新性在于將時間戳嵌入最高有效位（Most Significant Bits），實現了全局單調遞增。其 128 位結構如下：

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌─────────────────────┬─────┬─────┬─────────────────────────────┐
│   Unix毫秒時間戳    │ Ver │Var  │          隨機位            │
│      (48位)         │(4) │(2) │          (74位)            │
└─────────────────────┴─────┴─────┴─────────────────────────────┘

設計關鍵點解析：

高精度時間前綴（48位）：精確到毫秒的 Unix 時間戳，確保 ID 嚴格按時間遞增（需 NTP 時鐘同步）。
尾部隨機位（74位）：保證分布式唯一性，避免 v1 的 MAC 地址泄露風險。

有序性如何解決性能問題？

B+樹索引優化

新生成的 UUIDv7 總是大于之前的值，因此被追加到索引尾部，避免中間節點分裂。

緩沖池友好順序寫入使新記錄集中在少數數據頁。當頁寫滿時，數據庫只需分配新頁追加，減少舊頁淘汰與磁盤I/O。
范圍查詢加速時間有序性使 WHERE id > '2025-06-01' 可轉化為時間戳范圍過濾，大幅降低掃描范圍

3. UUIDv7 和其他版本的橫向對比

4.項目實戰：如何使用 UUIDv7？

生成 UUIDv7

import com.github.f4b6a3.uuid.UuidCreator;

public class UuidUtils {
    public static UUID generateUuidV7() {
        return UuidCreator.getTimeOrdered(); // 生成 UUIDv7
    }
    
     // 轉為數據庫存儲格式
    public static byte[] toBytes(UUID uuid) {
        ByteBuffer bb = ByteBuffer.wrap(new byte[16]);
        bb.putLong(uuid.getMostSignificantBits());
        bb.putLong(uuid.getLeastSignificantBits());
        return bb.array();
    }
    
    // 從數據庫讀取轉換
    public static UUID fromBytes(byte[] bytes) {
        ByteBuffer bb = ByteBuffer.wrap(bytes);
        return new UUID(bb.getLong(), bb.getLong());
    }
    
}

// 使用示例
UUID id = UuidService.generateUuidV7();

數據庫作為主鍵

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY, -- 二進制存儲 UUID
    name VARCHAR(50) NOT NULL,
    email VARCHAR(100)
);

插入數據庫和查詢

// 插入數據
UUID userId = UuidUtils.generateUuidV7();
String sql = "INSERT INTO users (id, name) VALUES (?, ?)";

try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setBytes(1, UuidUtils.toBytes(userId)); 
    ps.setString(2, "John Doe");
    ps.executeUpdate();
}

// 查詢數據
String query = "SELECT * FROM users WHERE id = ?";
try (PreparedStatement ps = conn.prepareStatement(query)) {
    ps.setBytes(1, UuidUtils.toBytes(userId));
    ResultSet rs = ps.executeQuery();
    while (rs.next()) {
        UUID id = UuidUtils.fromBytes(rs.getBytes("id"));
        String name = rs.getString("name");
    }
}

5. 關于UUIDv7 常見問題解答

5.1 UUIDv7到底會不會重復

極低概率，可視為唯一

UUIDv7由48位毫秒級Unix時間戳（約8.5萬年后才會耗盡） + 74位隨機數組成，總組合數達2^122（約5.3×10^36）。即使每秒生成10億個UUID，重復概率也遠低于10^-15，理論上可忽略。

極端場景，若系統時鐘回撥且在同一毫秒內生成大量UUID（超過2^74個），可能沖突，但實際中幾乎不可能發生。

5.2 什么是時鐘回撥？對UUIDv7有何影響？

原因：服務器時間因NTP同步錯誤、電源波動、虛擬機宿主機調整等意外回退。
問題：時鐘回撥后，新生成的UUIDv7時間戳可能小于前值，若回撥期間隨機數碰撞則可能重復
如何解決呢？

（1）預防措施：

使用冗余時鐘源：如GPS+原子鐘+NTP多層級同步，減少單點故障。
監控時鐘漂移：通過Kalman濾波等算法實時修正時間偏差。
避免虛擬機時鐘漂移：優先部署于物理機。

（2）生成時容錯：

時間戳延續：檢測到回撥時，延續最后記錄的時間戳直至超過回撥區間。
隨機數擴容：回撥期間擴展隨機數位數（如占用預留位），降低碰撞概率

責任編輯：武曉燕來源：撿田螺的小男孩

UUIDv7 數據庫主鍵