Máy tính Dung lượng Primary Key & Chỉ mục B-Tree

Mô hình hóa dung lượng lưu trữ, độ sâu B-Tree và phân mảnh Page Split giữa BIGINT, UUID v7, ULID và UUID v4

BIGINT (Nhỏ nhất)8 bytes
319.8 MB

100% tuần tự, 0% phân mảnh

UUID v7 (Khuyên dùng)16 bytes
339.2 MB

Chỉ +6% dung lượng, không rò rỉ ID

UUID v4 Text (Tồi tệ nhất)36 bytes
515.3 MB

Phình gấp 1.61x lần so với BIGINT

Working Set RAM ước tính
~170 MB

Cần thiết để giữ Index & Hot Data trong RAM

Tham số Cấu hình Cơ sở Dữ liệu

1,000,000
10K10M50M
3 chỉ mục
150 bytes
90%
Dữ liệu bảng (Heap / Clustered)
Chỉ mục Primary Key (B-Tree)
Chỉ mục phụ (Secondary Indexes)
PostgreSQL (8KB Page)
BIGINT (AUTO_INCREMENT / IDENTITY)Mốc chuẩn (Baseline)
3 tầng B-TreeGần như 0% (Tuần tự)
319.8 MB
Kích thước Key / Tuple:8 bytes (Binary)
Mật độ lấp đầy Page (Density):90%
Index phụ bị phình (Secondary Bloat):96 MB (1x)
Nguy cơ Cache Miss (RAM Working Set):~160 MB(Thấp)
UUID v7 (Time-Ordered 128-bit)Khuyên dùng (Gold Standard)
3 tầng B-TreeGần như 0% (Tuần tự)
339.2 MB(1.06x)
Kích thước Key / Tuple:16 bytes (Binary)
Mật độ lấp đầy Page (Density):90%
Index phụ bị phình (Secondary Bloat):96 MB (1x)
Nguy cơ Cache Miss (RAM Working Set):~170 MB(Thấp)
ULID (Universally Unique Lexicographically Sortable)
3 tầng B-TreeGần như 0% (Tuần tự)
339.2 MB(1.06x)
Kích thước Key / Tuple:16 bytes (Binary)
Mật độ lấp đầy Page (Density):90%
Index phụ bị phình (Secondary Bloat):96 MB (1x)
Nguy cơ Cache Miss (RAM Working Set):~170 MB(Thấp)
UUID v4 (Ngẫu nhiên - 16 bytes Binary / UUID type)
3 tầng B-TreeCực cao (50-70% Page Splits)
449.3 MB(1.4x)
Kích thước Key / Tuple:16 bytes (Binary)
Mật độ lấp đầy Page (Density):65% (Lãng phí 35% do Split)
Index phụ bị phình (Secondary Bloat):115.3 MB (1.2x)
Nguy cơ Cache Miss (RAM Working Set):~218 MB(Cao)
UUID v4 (Dạng chuỗi Text / CHAR(36))
3 tầng B-TreeCực cao (50-70% Page Splits)
515.3 MB(1.61x)
Kích thước Key / Tuple:36 bytes (Text)
Mật độ lấp đầy Page (Density):65% (Lãng phí 35% do Split)
Index phụ bị phình (Secondary Bloat):115.6 MB (1.2x)
Nguy cơ Cache Miss (RAM Working Set):~255 MB(Cao)
1,000,000 dòng•PostgreSQL (8KB)•UUID v7: 339.2 MB
FAQ
Nhóm Dữ liệu (Data)•Tài liệu kỹ thuật & Đặc tả RFC

Tài liệu & Hướng dẫn chuyên sâu: Máy tính Lưu trữ Primary Key & Chỉ mục B-Tree (Primary Key & B-Tree Storage Calculator)

1. Tổng quan & Nguyên lý hoạt động

Lựa chọn Primary Key là một trong những quyết định kiến trúc quan trọng nhất trong thiết kế cơ sở dữ liệu quan hệ (RDBMS). Một lựa chọn sai lầm có thể khiến dung lượng lưu trữ tăng gấp 2 đến 3 lần, làm vỡ mật độ trang B-Tree từ 90% xuống còn 65% do hiện tượng phân mảnh Page Splitting, và làm tràn Buffer Pool RAM dẫn đến tình trạng nghẽn cổ chai Disk I/O. Công cụ này cung cấp mô hình toán học tất định (deterministic model) so sánh chi tiết giữa BIGINT (8 bytes), UUID v7 (16 bytes sắp xếp theo thời gian), ULID và UUID v4 (ngẫu nhiên) trên cả 2 kiến trúc lưu trữ tiêu biểu: PostgreSQL (Heap Table 8KB) và MySQL InnoDB (Clustered Index Table 16KB).

2. Ưu thế kiến trúc & Tính năng nổi bật

Mô phỏng Phân mảnh B-Tree & Page Splitting

Mô hình hóa chính xác sự sụt giảm mật độ trang (Fill Factor) từ 90% xuống ~65% do hiện tượng phân chia trang ngẫu nhiên (50/50 page split) của UUID v4 so với ghi tuần tự phần đuôi của UUID v7 và BIGINT.

Phân tích Kiến trúc PostgreSQL vs MySQL InnoDB

Làm rõ sự khác biệt giữa bảng dạng Heap của PostgreSQL (chỉ mục phụ chỉ lưu con trỏ 6-byte CTID) và bảng Clustered Index của InnoDB (mọi chỉ mục phụ đều phải nhân bản toàn bộ khóa chính Primary Key).

Dự báo Kích thước Chỉ mục & Độ sâu Cây (B-Tree Levels)

Tính toán số lượng trang lá (Leaf Pages), trang nội bộ (Non-leaf Pages) và độ sâu B-Tree để ước tính số lần đọc đĩa (I/O Read) tối đa cho mỗi thao tác tìm kiếm khóa chính.

Ước tính Dung lượng Buffer Pool RAM & Nguy cơ Cache Miss

Đo lường dung lượng RAM tối thiểu cần thiết để duy trì toàn bộ tập chỉ mục và dữ liệu nóng trong bộ nhớ, cảnh báo nguy cơ suy giảm hiệu năng do Cache Eviction.

3. Bảng so sánh chi tiết các định dạng Primary Key trong Cơ sở dữ liệu

Tổng hợp các đặc tính kỹ thuật cốt lõi giữa các định dạng khóa chính phổ biến:

Loại Khóa ChínhKích thước Lưu trữĐặc tính Ghi B-TreeĐộ sâu B-Tree (10M dòng)Bảo mật ID (Chống Cào)Phù hợp nhất cho
BIGINT AUTO_INCREMENT8 bytes100% Tuần tự (0% Page Split)3 tầngKém (Rò rỉ số lượng bản ghi)Bảng nội bộ, logs, analytics, hệ thống đơn node
UUID v7 (RFC 9562)16 bytesTuần tự miligiây (Gần như 0% Split)3-4 tầngTuyệt đối an toàn (74-bit entropy)Chuẩn mực vàng cho SaaS, API công khai, Microservices
ULID16 bytes (hoặc 26 ký tự Base32)Tuần tự miligiây (Gần như 0% Split)3-4 tầngTuyệt đối an toàn (80-bit entropy)Hệ thống cần ID ngắn gọn, hiển thị URL thân thiện
UUID v4 (16B Binary)16 bytesNgẫu nhiên (50-70% Page Split)4 tầngTuyệt đối an toàn (122-bit entropy)Chỉ nên dùng cho bảng dữ liệu nhỏ (< 500.000 dòng)
UUID v4 (36B Text String)36 bytesNgẫu nhiên hoàn toàn (Tồi tệ nhất)4-5 tầngTuyệt đối an toàn (122-bit entropy)Anti-pattern! Cần refactor ngay lập tức sang UUID v7

4. Câu hỏi thường gặp (FAQ)

Giải đáp các thắc mắc phổ biến của lập trình viên khi sử dụng tiện ích Máy tính Lưu trữ Primary Key & Chỉ mục B-Tree (Primary Key & B-Tree Storage Calculator).

Cấu trúc B-Tree duy trì các khóa theo thứ tự sắp xếp liên tục. Khi bạn chèn một khóa tuần tự (như BIGINT hoặc UUID v7), khóa mới luôn nằm ở cuối trang lá bên phải cùng (Rightmost leaf page). Khi trang đầy, cơ sở dữ liệu chỉ cần cấp phát thêm một trang mới ở cuối và tiếp tục ghi với mật độ lấp đầy gần 100%. Ngược lại, với UUID v4 ngẫu nhiên, bản ghi mới rơi ngẫu nhiên vào giữa bất kỳ trang lá nào. Khi trang đó đã đầy, hệ thống buộc phải chia đôi trang làm 2 (50/50 Page Split), di chuyển một nửa dữ liệu sang trang mới, khiến mật độ lấp đầy trung bình sụp giảm xuống chỉ còn khoảng 65% (hoặc ln(2) ≈ 69.3%), gây lãng phí 35% dung lượng đĩa và làm vỡ cấu trúc bộ nhớ đệm.

5. Công cụ liên quan