Tạo UUID và GUID tức thì: Tích hợp công cụ này vào quy trình làm việc để tạo mã định danh an toàn mật mã, không thể trùng lặp cho cơ sở dữ liệu, hệ thống phân tán, payload API, dữ liệu kiểm thử và đặt tên file — ngay trong trình duyệt, không tiếp xúc máy chủ.

UUID là gì?

UUID (Universally Unique Identifier — Mã định danh duy nhất toàn cục) là nhãn 128 bit được chuẩn hóa theo RFC 9562 (công bố tháng 4 năm 2024, thay thế RFC 4122 từ năm 2005). Đặc điểm nổi bật là UUID có thể được tạo độc lập trên bất kỳ máy nào, vào bất kỳ thời điểm nào, không cần cơ quan điều phối trung tâm — và vẫn đảm bảo duy nhất về mặt thực tế trên toàn cầu.

Dạng văn bản chuẩn gồm 32 ký tự thập lục phân chia thành 5 nhóm bằng dấu gạch nối:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Trong đó M mã hóa phiên bản (thuật toán dùng để tạo UUID) và N mã hóa biến thể (quy tắc bố trí bit — luôn là 8, 9, a hoặc b cho UUID theo RFC 9562).

Ví dụ UUID v4 cụ thể:

550e8400-e29b-41d4-a716-446655440000

Đây là 32 ký tự hex = 128 bit dữ liệu. Vị trí các dấu gạch nối hoàn toàn mang tính thẩm mỹ và không mang thông tin — chúng được bỏ đi khi UUID được lưu ở dạng nhị phân hoặc rút gọn.

UUID “duy nhất toàn cầu” có thực sự duy nhất không?

UUID v4 dùng 122 bit ngẫu nhiên (6 bit dành cho siêu dữ liệu phiên bản và biến thể). Để hiểu rõ rủi ro trùng lặp: nếu bạn tạo 1 tỷ UUID mỗi giây, bạn cần duy trì tốc độ đó trong khoảng 85 năm để đạt xác suất 50% xuất hiện một lần trùng lặp. Với bất kỳ hệ thống thực tế nào, xác suất trùng lặp về cơ bản bằng không.

UUID và GUID — Có phải cùng một thứ không?

Có, với mục đích phát triển phần mềm hiện đại, UUID và GUID là như nhau.

GUID (Globally Unique Identifier) là thuật ngữ của Microsoft, ra đời cùng với COM/DCOM vào những năm 1990. GUID tuân theo cùng bố cục RFC 9562 và kích thước 128 bit. Sự khác biệt lịch sử duy nhất là cách Microsoft sắp xếp một số trường khi lưu trữ nhị phân — nhưng ở dạng chuỗi (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), UUID và GUID hoàn toàn giống nhau và có thể dùng thay thế cho nhau.

Thực tế: hệ sinh thái Windows và .NET thường dùng GUID, còn Linux, macOS, web API và cơ sở dữ liệu thường dùng UUID. Cả hai đều chỉ cùng một tiêu chuẩn.

Giải thích tất cả các phiên bản UUID

Số phiên bản không có nghĩa là “mới hơn là tốt hơn.” Nó xác định thuật toán được dùng để tạo UUID. Mỗi phiên bản giải quyết một vấn đề khác nhau.

Phiên bản	Thuật toán	Sắp xếp được	Trường hợp dùng
v1	Dấu thời gian + địa chỉ MAC	Một phần	Chỉ dùng cho hệ thống cũ
v2	DCE Security (POSIX UID/GID)	Không	Lỗi thời, tránh dùng
v3	Hash namespace bằng MD5	Không	ID xác định (MD5 đã bị phá, dùng v5 thay)
v4	Ngẫu nhiên	Không	Mục đích chung — lựa chọn mặc định an toàn
v5	Hash namespace bằng SHA-1	Không	ID xác định từ tên + namespace
v6	Dấu thời gian sắp xếp lại + ngẫu nhiên	Có	Lộ trình chuyển tiếp từ v1
v7	Dấu thời gian Unix + ngẫu nhiên	Có	Khóa chính cơ sở dữ liệu, hệ thống hiện đại

UUID v1 — Dấu thời gian và địa chỉ MAC

v1 mã hóa dấu thời gian hiện tại (theo khoảng 100 nanosecond kể từ tháng 10 năm 1582) cùng với địa chỉ MAC của máy tạo. Điều này cho phép sắp xếp theo thời gian một phần nhưng tiết lộ cả danh tính máy lẫn thời gian tạo trong chính UUID. Tránh dùng v1 trong bất kỳ API công khai hay hệ thống nào mà quyền riêng tư là quan trọng.

UUID v2 — DCE Security

v2 là biến thể của v1 thay thế một phần dấu thời gian bằng POSIX UID, GID hoặc định danh miền. Nó được thiết kế cho Distributed Computing Environments (DCE) đầu những năm 1990 và thực tế đã lỗi thời. Bạn khó gặp v2 ngoài cơ sở hạ tầng doanh nghiệp cũ.

UUID v3 — Hash namespace bằng MD5

v3 tạo UUID xác định bằng cách hash UUID namespace và tên với nhau bằng MD5. Với cùng namespace và tên, v3 luôn tạo ra cùng một UUID. Điều này hữu ích khi bạn cần mã định danh ổn định, có thể tái tạo cho một giá trị đã biết — nhưng MD5 đã bị phá vỡ về mặt mật mã. Dùng v5 thay thế cho mọi dự án mới.

UUID v4 — Hoàn toàn ngẫu nhiên (Lựa chọn mặc định cho mục đích chung)

v4 được tạo từ 122 bit dữ liệu ngẫu nhiên an toàn mật mã. Không dấu thời gian, không địa chỉ MAC, không siêu dữ liệu — chỉ là sự ngẫu nhiên. Ưu điểm:

• Đơn giản để tạo trên mọi ngôn ngữ và nền tảng
• Riêng tư — không tiết lộ bất cứ điều gì về thời điểm hay nơi tạo
• An toàn cho token, session ID và mã định danh công khai
• Được hỗ trợ rộng rãi trên mọi cơ sở dữ liệu, framework và API

UUID v4 là lựa chọn đúng cho 95% trường hợp sử dụng. Nếu bạn chỉ cần một ID duy nhất và hiệu suất chỉ mục cơ sở dữ liệu không phải vấn đề, dùng v4.

UUID v5 — Hash namespace bằng SHA-1

v5 hoạt động giống hệt v3 nhưng dùng SHA-1 thay vì MD5. Với cùng namespace và tên, nó luôn tạo ra cùng một UUID. Dùng v5 khi bạn cần tạo mã định danh có thể tái tạo, chống trùng lặp từ một đầu vào đã biết — ví dụ UUID ổn định cho một URL, địa chỉ email hoặc mã sản phẩm, được tạo từ một namespace đã biết.

UUID v6 — Dấu thời gian được sắp xếp lại

v6 là biến thể được tổ chức lại của v1, đặt dấu thời gian theo thứ tự big-endian để UUID v6 sắp xếp theo thứ tự thời gian. Nó chủ yếu tồn tại như cầu nối chuyển tiếp từ v1 sang v7 cho các hệ thống đang dùng v1. Với hệ thống mới, hãy dùng thẳng v7.

UUID v7 — Lựa chọn hiện đại cho khóa chính cơ sở dữ liệu

UUID v7 được chính thức hóa trong RFC 9562 (2024) và đang nhanh chóng trở thành lựa chọn mặc định được khuyến nghị cho các dự án mới dùng UUID làm khóa chính cơ sở dữ liệu.

v7 nhúng dấu thời gian Unix 48 bit tính bằng millisecond vào các bit có trọng số cao nhất, theo sau là dữ liệu ngẫu nhiên. Vì dấu thời gian ở đầu, UUID v7 có thể sắp xếp theo thứ tự từ điển — chúng sắp xếp theo thứ tự tạo cả dưới dạng chuỗi lẫn giá trị nhị phân.

019047b4-1c5e-7000-b703-24c3f6a5c849
│           │         │
└─ Dấu thời gian Unix 48 bit (ms)  └─ Các bit ngẫu nhiên

Thuộc tính sắp xếp này có ý nghĩa lớn đối với hiệu suất cơ sở dữ liệu.

UUID v4 so với UUID v7 — Nên dùng loại nào?

	UUID v4	UUID v7
Tạo	Hoàn toàn ngẫu nhiên	Dấu thời gian + ngẫu nhiên
Sắp xếp được	Không	Có (theo thời gian tạo)
Dấu thời gian nhúng	Không	Có (độ chính xác 48 bit ms)
Quyền riêng tư	Cao — không tiết lộ gì	Tiết lộ thời gian tạo
Hiệu suất chỉ mục DB	Kém ở quy mô lớn	Xuất sắc
Hỗ trợ trình duyệt	crypto.randomUUID()	Cần xây dựng thủ công
RFC	RFC 9562	RFC 9562

Dùng UUID v4 khi:

• Bạn cần token công khai, session ID hoặc tham chiếu không rõ nguồn gốc
• Ẩn thời gian tạo là quan trọng (token bảo mật, link mời)
• Hiệu suất chỉ mục cơ sở dữ liệu không phải điểm nghẽn

Dùng UUID v7 khi:

• UUID sẽ là khóa chính cơ sở dữ liệu
• Bạn muốn các bản ghi sắp xếp tự nhiên theo thời gian tạo mà không cần cột created_at riêng
• Bạn đang xây dựng hệ thống phân tán tạo ID trên nhiều node

UUID làm Khóa Chính Cơ Sở Dữ Liệu — Hướng Dẫn Hiệu Suất

Đây là nơi việc chọn phiên bản UUID có tác động kỹ thuật rõ ràng nhất.

Tại sao UUID v4 làm giảm hiệu suất cơ sở dữ liệu

Các cơ sở dữ liệu quan hệ như MySQL InnoDB và PostgreSQL dùng chỉ mục B-tree cho khóa chính. B-tree được tối ưu cho việc chèn tuần tự — mỗi hàng mới đi vào gần cuối trang đã ghi cuối cùng. Mẫu này lấp đầy trang hiệu quả và giảm thiểu I/O đĩa.

UUID v4 là ngẫu nhiên. Mỗi UUID mới chèn vào một vị trí ngẫu nhiên trong B-tree. Điều này gây ra:

• Phân tách trang: Engine thường xuyên phải phân tách các trang đầy để chèn ngẫu nhiên, làm phân mảnh chỉ mục
• Đẩy cache ra: Truy cập ngẫu nhiên nghĩa là engine phải liên tục tải các trang cũ từ đĩa thay vì làm việc ở đầu “nóng” của cây
• Lãng phí không gian: Mức sử dụng trang có thể giảm xuống 50% do phân mảnh
• Truy vấn phạm vi chậm hơn: Không có tính cục bộ theo thời gian — các hàng tạo gần nhau bị phân tán khắp chỉ mục

Ở số hàng thấp, điều này không nhìn thấy được. Ở hàng chục triệu hàng với thông lượng ghi liên tục, khóa chính UUID ngẫu nhiên gây ra suy giảm hiệu suất đáng kể.

Tại sao UUID v7 giải quyết vấn đề này

Tiền tố dấu thời gian của v7 nghĩa là mỗi UUID mới lớn hơn tất cả UUID đã tạo trước đó (trong cùng một millisecond, bộ đếm tuần tự hoặc các bit ngẫu nhiên duy trì thứ tự). B-tree nhận các lần chèn chỉ theo chiều phải — cùng mẫu hiệu quả như số nguyên tự tăng.

Các benchmark quy mô lớn cho thấy hiệu suất ghi nhanh hơn tới 400% với UUID có thứ tự so với v4 ngẫu nhiên, với phân mảnh chỉ mục thấp hơn tương ứng.

Lưu trữ nhị phân

Dù dùng v4 hay v7, lưu UUID dưới dạng chuỗi CHAR(36) lãng phí không gian. Dùng BINARY(16) hoặc kiểu UUID gốc của cơ sở dữ liệu:

• PostgreSQL: Kiểu UUID tích hợp (lưu trữ nội bộ dưới dạng 16 byte)
• MySQL: BINARY(16) hoặc các hàm UUID_TO_BIN() / BIN_TO_UUID() với đối số swap_flag=1 để chuyển các bit dấu thời gian lên đầu
• MongoDB: BSON subtype UUID gốc

Cách tạo UUID trong Code

JavaScript / Node.js

// Node.js 14.17+ và tất cả trình duyệt hiện đại
const id = crypto.randomUUID(); // UUID v4

// Node.js 19+ / thư viện bên thứ ba cho v7
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7();

Python

import uuid

id_v4 = str(uuid.uuid4())
id_v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))

Java

import java.util.UUID;

UUID id = UUID.randomUUID(); // v4
String idStr = id.toString();

C# / .NET

Guid id = Guid.NewGuid(); // v4
string idStr = id.ToString(); // "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

PostgreSQL

-- UUID v4 gốc (PostgreSQL 13+)
SELECT gen_random_uuid();

-- UUID v7 qua extension pg_uuidv7
SELECT uuid_generate_v7();

Go

import "github.com/google/uuid"

id := uuid.New()         // v4
idStr := id.String()

Tham chiếu Định dạng và Cấu trúc UUID

550e8400 - e29b - 41d4 - a716 - 446655440000
│          │      │      │      │
│          │      │      │      └── Node (48 bit)
│          │      │      └───────── Clock sequence (14 bit) + Biến thể (2 bit)
│          │      └──────────────── Phiên bản (4 bit) + Time mid (12 bit)
│          └─────────────────────── Time mid (16 bit)
└────────────────────────────────── Time low (32 bit)

Ký tự phiên bản (M): Ký tự thứ 13. 4 = ngẫu nhiên, 7 = có tiền tố dấu thời gian.

Bit biến thể (N): Ký tự thứ 17. Luôn là 8, 9, a hoặc b cho UUID theo RFC 9562 — hai bit này xác định UUID tuân theo bố cục RFC 9562 thay vì một sơ đồ độc quyền trước đó.

UUID đặc biệt

• UUID nil: 00000000-0000-0000-0000-000000000000 — tất cả bit bằng không, dùng làm giá trị null/sentinel
• UUID max: ffffffff-ffff-ffff-ffff-ffffffffffff — tất cả bit bằng một, RFC 9562 định nghĩa đây là UUID trường hợp đặc biệt hợp lệ

Các định dạng đầu ra

Cùng một giá trị UUID có thể được biểu diễn theo nhiều cách tùy hệ thống yêu cầu:

Định dạng	Ví dụ
Chuẩn (có gạch nối)	550e8400-e29b-41d4-a716-446655440000
Rút gọn (không gạch nối)	550e8400e29b41d4a716446655440000
Dấu ngoặc nhọn	{550e8400-e29b-41d4-a716-446655440000}
Chữ hoa	550E8400-E29B-41D4-A716-446655440000
URN	urn:uuid:550e8400-e29b-41d4-a716-446655440000

Các trường hợp sử dụng thực tế

1. Khóa chính cơ sở dữ liệu

UUID cho phép các hệ thống phân tán tạo khóa chính mà không cần bộ tạo tuần tự trung tâm. Không như số nguyên tự tăng, khóa chính UUID không tiết lộ tổng số hàng hay thứ tự chèn cho người gọi bên ngoài. Dùng UUID v7 cho các bảng mới khi bạn kiểm soát schema.

2. ID Hệ thống Phân tán — Không Cần Điều Phối

Trong kiến trúc microservices, nhiều service tạo bản ghi độc lập không thể chia sẻ một chuỗi tự tăng mà không có service điều phối. Mỗi node tạo UUID của riêng mình và chèn mà không sợ trùng lặp — ngay cả khi các service chưa bao giờ giao tiếp với nhau.

3. Khóa Idempotency cho Thanh toán và API

Các bộ xử lý thanh toán như Stripe và API hỗ trợ idempotency yêu cầu một khóa duy nhất cho mỗi request. Gửi cùng khóa idempotency hai lần sẽ trả về kết quả đã cache thay vì thực thi lại thao tác. UUID là định dạng tiêu chuẩn cho những khóa này.

4. Đặt tên File và Asset không thể trùng lặp

File được đặt tên bằng UUID không thể trùng lặp dù bao nhiêu người dùng tải lên đồng thời. Các đối tượng được đặt tên UUID trong S3, GCS hoặc bất kỳ blob store nào đều an toàn để tạo song song mà không cần chiến lược khóa.

5. Session và Token Định danh

UUID được dùng rộng rãi làm session ID, token đặt lại mật khẩu, link xác minh email và mã mời. Dùng v4 cho những trường hợp này — sự ngẫu nhiên không rõ nguồn gốc không tiết lộ siêu dữ liệu về thời điểm token được cấp.

6. ID Xác định từ Đầu vào đã Biết (v5)

Khi bạn cần một UUID ổn định, có thể tái tạo cho một đầu vào đã cho — UUID chuẩn cho một URL, mã sản phẩm hoặc email người dùng — hãy tạo bằng UUID v5 với namespace cố định. Cùng đầu vào luôn tạo ra cùng UUID, giúp tạo ID an toàn mà không cần tra cứu trong cơ sở dữ liệu trước.

Cách dùng công cụ tạo UUID này

1. Nhập số lượng UUID bạn cần (1 đến 1000).
2. Chọn định dạng đầu ra: chuẩn có gạch nối, rút gọn, dấu ngoặc nhọn hoặc chữ hoa.
3. Nhấn Tạo UUID, hoặc bật Tự động tạo để tạo ID mới mỗi khi tải trang.
4. Nhấn Sao chép để sao chép tất cả ID vào clipboard, hoặc Tải xuống để lưu dưới dạng file .txt.
5. Để chuẩn hóa UUID có sẵn, dán chúng vào bảng thứ hai. Công cụ xác thực từng giá trị và chuyển về định dạng chuẩn chữ thường có gạch nối.

Truyền dữ liệu bằng tham số URL

Điền trước số lượng tạo qua URL:

https://www.uprek.com/vi/tools/tao-uuid-guid?count=25

Điền trước bảng chuẩn hóa với chuỗi UUID có sẵn:

https://www.uprek.com/vi/tools/tao-uuid-guid?input=123e4567e89b42d3a456426614174000

Dữ liệu của bạn không bao giờ rời trình duyệt

Khi bạn dùng công cụ này trong bối cảnh chuyên nghiệp — điền dữ liệu seed cho cơ sở dữ liệu, tạo ID cho công cụ nội bộ hoặc chuẩn hóa UUID từ bản xuất sản xuất — bạn không nên cần gửi dữ liệu đó đến máy chủ bên thứ ba.

Tại UPREK, kiến trúc của chúng tôi nghiêm ngặt: dữ liệu của bạn là của bạn. Chúng tôi không muốn nó, không thu thập nó và không thể thấy nó.

• Tạo 100% cục bộ: UUID được tạo bằng API gốc của trình duyệt crypto.randomUUID(), hoặc crypto.getRandomValues() như dự phòng — cả hai đều chạy hoàn toàn trong JavaScript engine của trình duyệt.
• Không tải lên máy chủ: Không có UUID nào bạn tạo hoặc dán vào công cụ này được truyền đến máy chủ của chúng tôi.
• Không ghi log hay lưu trữ: Chúng tôi không ghi log, lưu trữ hay kiểm tra bất kỳ mã định danh hay văn bản đầu vào nào bạn làm việc.
• Xóa tức thì: Tất cả dữ liệu được tạo chỉ tồn tại trong bộ nhớ hoạt động của trình duyệt. Đóng tab và nó biến mất.

Câu hỏi thường gặp

Nhật ký thay đổi