Trong MySQL, khái niệm Primary Key và Unique Key khác nhau như thế nào, và việc lựa chọn sai kiểu dữ liệu hoặc cấu trúc cho Primary Key có thể gây ra những vấn đề gì về hiệu năng InnoDB?

Question

Accepted Answer

1. Phân biệt Primary Key và Unique Key

Primary Key (Khóa chính):
Mỗi bảng chỉ được phép có duy nhất một Primary Key.
Giá trị trong cột này không được phép NULL và phải là duy nhất (Unique).
Đối với storage engine InnoDB, Primary Key quyết định cách mà dữ liệu được sắp xếp và lưu trữ vật lý trên ổ đĩa (được gọi là Clustered Index).

Unique Key (Khóa duy nhất):
Một bảng có thể có nhiều Unique Key.
Cho phép chứa giá trị NULL (tuy nhiên tùy thuộc vào phiên bản và thiết kế, thông thường chỉ cho phép một giá trị NULL trong chuẩn SQL nghiêm ngặt, nhưng MySQL cho phép nhiều giá trị NULL trừ khi có ràng buộc bổ sung).
Được lưu trữ dưới dạng Secondary Index (Index phụ), bên trong chứa giá trị của cột đó và trỏ về giá trị của Primary Key tương ứng.

2. Tác động hiệu năng khi chọn sai Primary Key trong InnoDB

Sử dụng chuỗi ngẫu nhiên (UUID/GUID) làm Primary Key:
UUID hoàn toàn ngẫu nhiên và không có tính tuần tự. Khi chèn (Insert) dữ liệu mới vào bảng InnoDB sử dụng Clustered Index, dữ liệu phải được đặt đúng vị trí theo thứ tự của Primary Key.
Điều này gây ra hiện tượng Page Splitting (chia tách trang dữ liệu) liên tục trên RAM và ổ đĩa, làm giảm hiệu suất ghi (Write Performance) nghiêm trọng và tăng phân mảnh ổ đĩa.

Giải pháp tối ưu:
Nên sử dụng kiểu số nguyên tăng tự động (INT AUTO_INCREMENT hoặc BIGINT AUTO_INCREMENT) hoặc sử dụng thuật toán sắp xếp thời gian như UUID v7 / ULID nếu bắt buộc phải dùng chuỗi phân tán.

3. Ví dụ thực chiến
-- Thiết kế tốt cho InnoDB
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;
Kinh nghiệm thực tế cho thấy việc tuân thủ quy tắc dùng số nguyên tăng dần cho Primary Key giúp tiết kiệm không gian bộ nhớ đệm (Buffer Pool) và tối ưu hóa tốc độ truy vấn JOIN.