P7領導建議：可以用UUIDv7作為數據庫主鍵
作者：田螺
我們提到分布式主鍵ID的時候，可能都會想到UUID，比如在設計數據庫主鍵的時候。但是可能最終都不會考慮它。但是呢，最近領導卻建議說，可以考慮它作為數據庫主鍵了，因為UUIDv7的出現~~
前言
大家好，我是田螺。
我們提到分布式主鍵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）生成時容錯：
- 時間戳延續：檢測到回撥時，延續最后記錄的時間戳直至超過回撥區間。
- 隨機數擴容：回撥期間擴展隨機數位數（如占用預留位），降低碰撞概率
責任編輯：武曉燕
來源：
撿田螺的小男孩
