Giải Thích Các Kiểu Dữ Liệu MySQL: Lựa Chọn Kiểu Cột Phù Hợp Để Tối Ưu Hiệu Năng và Khả Năng Mở Rộng

1. Giới thiệu: Tại sao bạn nên hiểu danh sách kiểu dữ liệu MySQL

Khi bạn thiết kế bảng hoặc tích hợp ứng dụng với MySQL, một trong những câu hỏi phổ biến nhất là: “Kiểu dữ liệu nào nên dùng cho cột này?”
Có nên dùng INT? Bạn có thực sự cần BIGINT không? VARCHAR có đủ cho chuỗi, hay TEXT tốt hơn? Những lựa chọn này có vẻ nhỏ nhặt, nhưng chúng tạo nên nền tảng ảnh hưởng đến hệ thống của bạn sau này.

Nếu bạn đánh giá thấp việc lựa chọn kiểu dữ liệu, bạn thường sẽ gặp các vấn đề như sau:

• Khi dữ liệu của bạn tăng vượt dự đoán, bạn lãng phí không gian lưu trữ
• Các chỉ mục phình to và hiệu năng truy vấn dần giảm sút
• Giá trị vượt phạm vi hoặc tràn gây ra lỗi hoặc ngoại lệ không mong muốn
• Bạn buộc phải thay đổi kiểu cột sau này, dẫn đến việc di chuyển quy mô lớn

Nói cách khác, hiểu một cách có hệ thống các kiểu dữ liệu MySQL và chọn đúng kiểu cho mỗi trường hợp sử dụng là cách nhanh nhất để cải thiện cả hiệu năng và khả năng bảo trì.

Trang này chủ yếu hướng tới các độc giả như:

• Kỹ sư đang chuẩn bị bắt đầu phát triển hệ thống nghiêm túc với MySQL
• Kỹ sư backend / hạ tầng muốn xem lại thiết kế bảng hiện có
• Nhà phát triển web và lập trình viên muốn “kiểu đề xuất” theo từng trường hợp sử dụng

Chúng tôi sẽ bắt đầu bằng cách sắp xếp các kiểu dữ liệu MySQL chính thành một “danh sách” được phân loại. Sau đó, chúng tôi sẽ giải thích các kiểu quan trọng—số, chuỗi, ngày/giờ, JSON, ENUM/SET—bao gồm đặc điểm, trường hợp sử dụng điển hình và mẹo lựa chọn. Cuối cùng, chúng tôi sẽ tóm tắt các lỗi thiết kế thường gặp và cách tránh chúng, cùng với phần Hỏi đáp.

Đây không chỉ là một “danh sách các thuật ngữ”. Nó được cấu trúc như hướng dẫn ra quyết định để bạn không bị kẹt khi thiết kế bảng trong các dự án thực tế. Trong phần tiếp theo, hãy cùng khám phá cách suy nghĩ về kiểu dữ liệu và xem lại danh sách đã phân loại.

2. Kiểu dữ liệu là gì, và tại sao “chọn đúng kiểu” lại quan trọng?

Trong cơ sở dữ liệu, “kiểu dữ liệu” là một quy tắc xác định loại giá trị mà một cột có thể lưu trữ.
MySQL cung cấp nhiều kiểu dữ liệu—số nguyên, thập phân, chuỗi, ngày, nhị phân, JSON và hơn thế nữa—do đó bạn cần chọn phù hợp tùy theo mục đích.

Vai trò của Kiểu dữ liệu

Một kiểu dữ liệu không chỉ là một “danh mục định dạng”. Nó thực hiện nhiều vai trò đồng thời:

• Hạn chế loại dữ liệu (số so với chuỗi, boolean, v.v.)
• Xác định phạm vi cho phép và số chữ số
• Xác định bộ nhớ cần thiết (kích thước lưu trữ)
• Ảnh hưởng đến cấu trúc chỉ mục và hiệu năng tìm kiếm
• Gây ảnh hưởng đến việc chuyển đổi ngầm và quy tắc so sánh (ví dụ, collation của chuỗi)

Tóm lại, kiểu dữ liệu không chỉ là “bộ chứa”—chúng là các lựa chọn thiết kế nền tảng ảnh hưởng đến toàn bộ vòng đời quản lý dữ liệu.

Điều gì xảy ra nếu bạn chọn sai kiểu?

Nếu bạn chọn sai kiểu dữ liệu, các vấn đề như sau thường xảy ra trong thực tế:

• Lãng phí lưu trữ

Ví dụ, nếu BIGINT (8 byte) là đủ nhưng bạn nhầm lẫn sử dụng DECIMAL hoặc LONGTEXT, bạn có thể tiêu tốn nhiều không gian đĩa hơn rất nhiều so với dự kiến.

• Truy vấn chậm hơn

Nếu bạn lạm dụng tìm kiếm LIKE trên các cột TEXT khổng lồ, hoặc nếu chỉ mục phình to vì bạn chọn các kiểu số quá lớn, việc thực thi SQL sẽ chậm lại.

• Giá trị không nhất quán hoặc tràn

Bạn có thể lưu các giá trị không vừa trong INT, gây ra giá trị âm không mong muốn, làm tròn hoặc các vấn đề khác.

• Thay đổi bảng tốn kém

Đặc biệt trên các bảng lớn, việc thay đổi kiểu bằng ALTER TABLE có thể dẫn đến:

• Thời gian khóa lâu
• Ảnh hưởng đến dịch vụ
• Công việc di chuyển dữ liệu và các rủi ro khác.

Các danh mục chính bạn nên hiểu ngay từ đầu

Các kiểu dữ liệu MySQL được phân loại rộng rãi như sau:

• Kiểu số (số nguyên, thập phân)
• Kiểu chuỗi
• Kiểu ngày và giờ
• Kiểu nhị phân
• Kiểu JSON
• Kiểu ENUM / SET
• Kiểu dữ liệu không gian

Mỗi loại có những ưu nhược điểm khác nhau—điểm mạnh/yếu, “nhẹ vs. nặng,” và “dễ vs. khó tìm kiếm.” Đó là lý do bạn cần lựa chọn loại tối ưu cho từng trường hợp sử dụng.

3. Các Loại Dữ Liệu MySQL (Danh Sách Tổng Quan)

Trong phần này, chúng ta sẽ tóm tắt các loại dữ liệu có sẵn trong MySQL dưới dạng danh sách tổng quan theo loại. Trong thực tế, những điều đầu tiên bạn muốn xác nhận là “Có những loại nào?” và “Nên sử dụng loại nào?”
Vì vậy, ở đây chúng ta sẽ trình bày rõ ràng các trường hợp sử dụng, đặc điểm chính, và tên loại đại diện, sau đó giải thích chi tiết từng loại trong các phần sau.

3.1 Các Loại Số

Các loại số là nền tảng cho tất cả xử lý số, bao gồm số nguyên, thập phân, và giá trị dấu phẩy động.
Loại này được sử dụng thường xuyên nhất cho ID, số lượng, giá cả, kiểm tra cờ, và nhiều mục đích khác.

Các Loại Số Nguyên

Ghi Chú

• Thêm UNSIGNED sẽ nhân đôi phạm vi dương.
• INT được sử dụng trong nhiều trường hợp, nhưng sử dụng BIGINT một cách tùy tiện có thể làm cho chỉ mục nặng hơn.

Các Loại Thập Phân / Dấu Phẩy Động

Ghi Chú

• Đối với tiền tệ, DECIMAL là lựa chọn hợp lý duy nhất . Các loại dấu phẩy động ( FLOAT / DOUBLE ) có thể gây ra lỗi.
• Nếu bạn thực hiện nhiều phép tính, một số trường hợp chọn DOUBLE để đánh đổi tốc độ/độ chính xác.

Các Loại Số Khác

3.2 Các Loại Ngày và Giờ

Xử lý ngày/giờ được sử dụng rất thường xuyên trong phát triển ứng dụng.
Tùy thuộc vào mục đích, các yếu tố như “hành vi múi giờ,” “cập nhật tự động,” và “độ chính xác cấp giây” khác nhau, vì vậy việc chọn loại đúng rất quan trọng.

Ghi Chú

• Nếu bạn muốn quản lý “cập nhật lúc” tự động, TIMESTAMP rất tiện lợi.
• Đối với “nhật ký” hoặc “lịch sử” nơi bạn muốn lưu trữ dấu thời gian chính xác, DATETIME thường được sử dụng.

3.3 Các Loại Chuỗi / Nhị Phân

Tên người dùng, email, mật khẩu, mô tả—chuỗi thường là lĩnh vực phức tạp nhất trong thiết kế bảng.

Chuỗi Độ Dài Cố Định

Chuỗi Độ Dài Biến Đổi

Văn Bản Lớn (Gia Đình TEXT)

Ghi Nhớ

• Sử dụng TEXT khi bạn cần lưu trữ chuỗi rất lớn như nội dung bài viết hoặc mô tả dài.
• Hãy cẩn thận với thiết kế tìm kiếm và chỉ mục.

Dữ Liệu Nhị Phân (BINARY / BLOB)

※ Nói chung, các tệp lớn không được lưu trữ trong cơ sở dữ liệu; thiết kế phổ biến là lưu trữ chúng trong lưu trữ bên ngoài thay thế.

Các Loại ENUM / SET (Liệt Kê)

Cảnh Báo

• Nếu bạn cần thay đổi định nghĩa loại sau này, việc bảo trì sẽ trở nên nặng nề
• Nó có thể hiệu quả cho các ứng cử viên quy mô nhỏ, tĩnh

3.4 Loại JSON

• Bạn có được sự linh hoạt giống NoSQL trong khi vẫn có thể sử dụng các hàm cụ thể cho JSON.
• Tuy nhiên, không khuyến khích đóng gói dữ liệu tìm kiếm thường xuyên vào JSON . Nếu có thể chuẩn hóa, nó nên được mô hình hóa dưới dạng bảng có cấu trúc.

3.5 Các Loại Không Gian

Những loại này được sử dụng khi làm việc với dữ liệu địa lý và vị trí.

Trong các ứng dụng web điển hình, những loại này không được sử dụng thường xuyên, nhưng chúng quan trọng cho ứng dụng bản đồ và tích hợp GPS.

4. Cách Chọn và Sử Dụng Mỗi Loại Dữ Liệu (Các Điểm Quyết Định Chính)

Ở đây chúng ta đi sâu hơn vào các loại đã giới thiệu ở trên, tập trung vào “cách chọn trong công việc thực tế.”
Chỉ biết tên là không đủ—chọn loại dữ liệu phù hợp nhất có tác động lớn đến khả năng bảo trì, hiệu suất, và khả năng mở rộng trong tương lai.

4.1 Cách Chọn Các Loại Số

Tiêu Chí Chọn Các Loại Số Nguyên

Khi chọn các loại số nguyên, hãy tập trung vào ba điểm này:

1. Hiểu Phạm Vi Tối Đa Cần Thiết

• Bộ đếm nhỏ → TINYINT
• Số lượng sản phẩm / cờ → SMALLINT / INT
• ID quy mô lớn hoặc nhật ký → BIGINT

Một số dự án lạm dụng BIGINT cho khóa chính, nhưng điều này có thể dễ dàng tạo ra kích thước chỉ mục không cần thiết và có thể bất lợi cho hiệu suất.

2. Xem Xét Kích Hoạt UNSIGNED

Nếu bạn chỉ xử lý các giá trị dương (ví dụ: ID số, số lượng tồn kho) → sử dụng UNSIGNED sẽ gấp đôi phạm vi và có thể cho phép bạn dùng kiểu dữ liệu nhỏ hơn.

3. Đối với Tiền tệ hoặc Các Giá trị Yêu cầu Độ chính xác Cao, Hãy Sử dụng DECIMAL

Đối với các giá trị mà “lỗi không chấp nhận được”, tránh dùng FLOAT/DOUBLE và luôn sử dụng DECIMAL.

4.2 Cách Chọn Kiểu Dữ liệu Ngày và Giờ

Kiểu dữ liệu phù hợp phụ thuộc vào trường hợp sử dụng của bạn.

Sự Khác Biệt Giữa DATETIME và TIMESTAMP

Các Quy Tắc Chung Khi Lựa Chọn

• Nhật ký ứng dụng hoặc bản ghi sự kiện → DATETIME (tránh ảnh hưởng của chuyển đổi múi giờ)
• Khi bạn muốn tự động ghi lại thời gian cập nhật → TIMESTAMP (hành vi tự động cập nhật tiện lợi)

Khi Nào Năm (YEAR) Thực Sự Hữu Ích

• Các danh mục năm tài chính, năm phát hành, năm thành lập, v.v. → Quản lý gọn gàng (1 byte)

4.3 Cách Chọn Kiểu Dữ liệu Chuỗi

Cách Quyết Định Giữa CHAR và VARCHAR

Khi Nên Sử Dụng CHAR

• Độ dài luôn cố định: mã tỉnh, mã quốc gia, định danh có độ dài cố định, v.v.
• Dữ liệu cần truy cập nhanh và ít được cập nhật

Khi Nên Sử Dụng VARCHAR

• Độ dài thay đổi: tên, địa chỉ email, tiêu đề, v.v.
• Lựa chọn mặc định tốt nhất trong hầu hết các tình huống

Bạn Có Nên Sử Dụng TEXT?

Ưu Điểm của TEXT

• Hỗ trợ văn bản lớn (mô tả, nội dung bài viết, v.v.)

Lưu Ý Khi Sử Dụng TEXT

• Việc tạo chỉ mục bị hạn chế (cần chỉ mục tiền tố)
• Hiệu năng có thể giảm khi dùng trong JOIN hoặc mệnh đề WHERE
• Tìm kiếm và sắp xếp có thể tốn kém

Khuyến nghị:
Sử dụng TEXT cho “chuỗi lớn” như nội dung hoặc ghi chú,
và sử dụng VARCHAR càng nhiều càng tốt cho các trường hợp còn lại.

4.4 Cách Chọn Kiểu Dữ liệu JSON

Kiểu dữ liệu JSON rất hữu ích, nhưng bạn cần sử dụng nó “đúng cách”.

Khi JSON Hoạt Động Tốt

• Cài đặt linh hoạt hoặc dữ liệu có số trường thay đổi
• Trường hợp tra cứu hạn chế, hoặc khi ứng dụng mở rộng/giải mã nó
• Lưu trữ dữ liệu nhẹ không cần bảng chính

Khi JSON Không Phù Hợp

• Dữ liệu bạn thường xuyên tìm kiếm
• Dữ liệu dùng cho tìm kiếm có bộ lọc, tổng hợp, hoặc JOIN
• Dữ liệu có cấu trúc nên được chuẩn hoá

Nguyên tắc chung:
Dữ liệu bạn cần tìm kiếm nên được chuẩn hoá và coi như cấu trúc.
Đừng quên rằng JSON “linh hoạt nhưng yếu trong việc tìm kiếm”.

4.5 Cách Chọn Kiểu ENUM / SET

Khi ENUM Thích Hợp

• Trạng thái cố định: ví dụ, trạng thái (draft / published / archived).
• Một tập hợp nhỏ các tùy chọn hiếm khi thay đổi.

Lưu Ý Khi Dùng ENUM

• Thêm hoặc thay đổi giá trị yêu cầu ALTER TABLE.
• Nguy cơ mất tính nhất quán với định nghĩa phía ứng dụng.

Khi SET Thích Hợp

• Dữ liệu quy mô nhỏ cần chọn nhiều giá trị (ví dụ, các ngày trong tuần khả dụng, hoặc khi chỉ có một vài tùy chọn thẻ).

Lưu Ý Khi Dùng SET

• Các tổ hợp giá trị có thể trở nên phức tạp.
• Quản lý trạng thái đa giá trị có thể trở nên khó khăn.

4.6 Cách Chọn Kiểu Binary / BLOB

BINARY / VARBINARY

• Token, ID, giá trị băm, v.v.
• Dữ liệu nhị phân độ dài cố định (ví dụ, UUID 16 byte).

Các Trường Hợp Sử Dụng Thông Thường cho Kiểu BLOB

• Tệp nhỏ, hình ảnh thu nhỏ, dữ liệu đã mã hoá.

Tuy nhiên Lưu Ý

• Lưu trữ tệp lớn trong cơ sở dữ liệu làm tăng kích thước sao lưu.
• Tải đọc/ghi cũng tăng → Trong các hệ thống thực tế, nên dùng lưu trữ ngoài + quản lý đường dẫn.

5. Thực Hành: Cách Sử Dụng “Danh Sách Tham Khảo Kiểu Dữ Liệu” Khi Thiết Kế Bảng

Trong phần này, chúng tôi sẽ giải thích cách sử dụng danh sách kiểu dữ liệu MySQL trong quy trình thực tế khi thiết kế bảng. Thay vì chỉ ghi nhớ các kiểu, việc tổ chức “lý do bạn chọn kiểu đó” qua logic và các bước sẽ dẫn đến thiết kế cơ sở dữ liệu chất lượng cao hơn.

5.1 Bước 1: Làm Rõ “Mục Đích” và “Bản Chất” của Cột

Đầu tiên, xác định rõ ràng những gì sẽ được lưu trong cột.

Danh Sách Kiểm Tra

• Nó là kiểu số, chuỗi, ngày hay một cờ?
• Nó có độ dài biến đổi hay cố định?
• Giá trị tối đa hoặc độ dài tối đa là bao nhiêu?
• Có cho phép NULL không?
• Có khả năng sẽ tăng trong tương lai không?

Nếu bạn tiếp tục với các giả định mơ hồ ở đây, việc lựa chọn kiểu dữ liệu sẽ trở nên phức tạp không cần thiết sau này.

5.2 Bước 2: Ước tính Phạm vi và Định dạng Yêu cầu

Tiếp theo, ước tính giới hạn trên/dưới, độ dài ký tự và độ chính xác cần thiết của các giá trị bạn sẽ lưu trữ.

Ví dụ: Cột ID

• Số lượng bản ghi tối đa có đạt tới hàng chục triệu? Hàng trăm triệu? → Điều này giúp bạn xác định liệu INT có đủ hay cần BIGINT.

Ví dụ: Tên Sản phẩm

• Trung bình 15–25 ký tự, tối đa khoảng 50? → VARCHAR(50) là đủ. TEXT không cần thiết.

Ví dụ: Giá

• Cần độ chính xác không? → Bạn nên chọn kiểu như DECIMAL(10,2).

5.3 Bước 3: Xem xét Khối lượng Dữ liệu và Hiệu suất

Việc chọn kiểu dữ liệu MySQL ảnh hưởng trực tiếp đến hiệu suất.

Các Yếu tố Chính

• Kiểu dữ liệu quá lớn → tiêu tốn dung lượng lưu trữ và làm chỉ mục nặng hơn
• TEXT / BLOB → làm giảm hiệu suất tìm kiếm
• JSON → linh hoạt nhưng kém trong việc tìm kiếm
• TIMESTAMP → hiệu quả cho việc cập nhật tự động và so sánh

Đặc biệt, các cột có chỉ mục nên sử dụng kiểu dữ liệu nhẹ nhất có thể.

5.4 Bước 4: Xác thực Kiểu Dữ liệu với Dữ liệu Mẫu

Sau khi thiết kế bảng, chèn từ vài chục đến hàng trăm dòng dữ liệu thử nghiệm và kiểm tra hành vi.

Những Điều Cần Kiểm Tra

• Có vấn đề làm tròn hoặc cắt ngắn không mong muốn không?
• VARCHAR có đủ không, hay nên dùng TEXT?
• Việc sắp xếp và tìm kiếm ngày giờ có hoạt động như mong đợi không?
• Hiệu suất đọc/ghi JSON

Kiểm tra với dữ liệu thực tế giảm thiểu “sự đánh giá sai lệch lý thuyết”.

5.5 Bước 5: Xem xét Khả năng Mở rộng và Bảo trì

Ở giai đoạn cuối của việc thiết kế bảng, kiểm tra xem các thay đổi trong tương lai có dễ thực hiện không.

Ví dụ về Các Thay đổi Kiểu Dữ liệu Nặng

• ENUM (cần ALTER TABLE khi thêm giá trị)
• TEXT → VARCHAR (mở rộng dễ, thu hẹp rủi ro)
• FLOAT → DECIMAL (có thể thay đổi ngữ nghĩa)

Chọn kiểu dữ liệu dựa trên việc đánh giá khả năng mở rộng trong tương lai.

5.6 Bước 6: Ví dụ CREATE TABLE (Mẫu Thực tế)

Dưới đây là một bảng ví dụ phản ánh các tiêu chuẩn lựa chọn kiểu dữ liệu phổ biến trong một ứng dụng web điển hình.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Các Điểm Chính trong Ví dụ Này

• id : Sử dụng BIGINT UNSIGNED cân nhắc quy mô tương lai
• name : Chuỗi biến độ dài trung bình → VARCHAR
• price : Giá trị tiền tệ → DECIMAL chính xác
• stock : Số lượng tồn kho → INT UNSIGNED
• status : Tập hợp giá trị cố định → ENUM
• description : Văn bản dài có thể → TEXT
• updated_at : TIMESTAMP tự cập nhật tiện lợi

Như đã chỉ ra, mỗi lựa chọn kiểu dữ liệu nên có lý do rõ ràng, và khả năng giải thích lý do đó là dấu hiệu của một thiết kế tốt.

6. Những Sai lầm Thường gặp và Cách Tránh

Vì MySQL cung cấp nhiều kiểu dữ liệu, một số sai lầm phổ biến thường xuất hiện trong các dự án thực tế.
Phần này nêu bật các bẫy thường gặp và đưa ra các biện pháp thực tế.

6.1 Sử dụng Kiểu Dữ liệu Quá lớn

Các Ví dụ Thông thường

• Đặt tất cả ID thành BIGINT
• Đặt mọi chuỗi thành VARCHAR(255)
• Sử dụng TEXT cho nội dung không phải văn bản

Vấn đề

• Lãng phí dung lượng lưu trữ
• Chỉ mục phình to làm giảm hiệu suất truy vấn
• Lãng phí băng thông mạng (truyền dữ liệu lớn hơn)

Cách Tránh

• Ước tính giá trị tối đa và tối thiểu trước
• Đặt độ dài VARCHAR dựa trên bằng chứng
• Chỉ sử dụng TEXT khi thực sự cần thiết

6.2 Sử dụng FLOAT/DOUBLE cho các giá trị thập phân (Vấn đề độ chính xác)

Ví dụ thường gặp

• Lưu giá trị giá cả dưới dạng FLOAT
• So sánh số học thất bại do lỗi làm tròn

Cách tránh

• Sử dụng DECIMAL cho tiền tệ và các giá trị yêu cầu độ chính xác cao
• Tránh FLOAT / DOUBLE ngoại trừ các tính toán khoa học hoặc tạm thời

6.3 Cột VARCHAR quá lớn

Ví dụ thường gặp

• Sử dụng VARCHAR(255) làm mặc định
• Đặt độ dài lớn cho các cột chỉ lưu khoảng 30 ký tự

Vấn đề

• Lãng phí bộ nhớ và không gian lưu trữ
• Các chỉ mục thường trở nên nặng hơn

Cách tránh

• Ước tính độ dài trung bình và tối đa dựa trên dữ liệu thực tế
• Tránh kích thước quá lớn không cần thiết (ví dụ: địa chỉ email → VARCHAR(100) )

6.4 Sử dụng quá mức các kiểu TEXT

Ví dụ thường gặp

• Giả định “chuỗi = TEXT”
• Sử dụng TEXT cho dữ liệu cần lọc hoặc tìm kiếm

Vấn đề

• Nhiều hạn chế về chỉ mục
• Các truy vấn LIKE nặng
• Xử lý chậm hơn trong các JOIN

Cách tránh

• Chỉ sử dụng TEXT cho nội dung dài như mô tả hoặc thân bài
• Lưu các chuỗi có thể tìm kiếm trong VARCHAR bất cứ khi nào có thể

6.5 Chọn kiểu ngày/giờ mà không hiểu thuộc tính của chúng

Ví dụ thường gặp

• Sử dụng DATETIME cho mọi thứ
• Sử dụng DATETIME cho “updated at”, vì vậy nó không tự động cập nhật
• Thời gian dấu thời gian (timestamp) bị dịch do sự khác biệt múi giờ

Cách tránh

• Cần tự động cập nhật: TIMESTAMP
• Muốn tránh sự dịch chuyển múi giờ: DATETIME
• Chỉ cần năm: YEAR

6.6 Sử dụng ENUM / SET một cách tùy tiện

Ví dụ thường gặp

• Sử dụng ENUM mặc dù các tùy chọn có thể thay đổi trong tương lai
• Sử dụng SET như một danh sách phân tách bằng dấu phẩy

Vấn đề

• Thay đổi yêu cầu ALTER TABLE
• Sự không nhất quán với định nghĩa phía ứng dụng dễ xảy ra hơn

Cách tránh

• Nếu các giá trị có thể tăng, quản lý chúng trong một bảng master riêng
• Chỉ sử dụng ENUM khi tập hợp nhỏ và thực sự cố định

6.7 Đóng gói quá nhiều vào JSON “Vì nó tiện lợi”

Ví dụ thường gặp

• Đóng gói các cấu trúc nên được chuẩn hoá vào JSON
• Lưu dữ liệu thường xuyên được tìm kiếm bên trong JSON

Vấn đề

• Hiệu năng tìm kiếm giảm sút
• Các chỉ mục kém hiệu quả / khó sử dụng hơn
• Tăng khối lượng công việc phân tích phía ứng dụng
• Thiết kế không có schema khiến việc duy trì tính nhất quán trở nên dễ bị phá vỡ

Cách tránh

• Chỉ sử dụng JSON cho dữ liệu không cần tìm kiếm
• Giới hạn nó cho “dữ liệu nhỏ, biến đổi” như cài đặt
• Chuẩn hoá thông tin được dùng cho JOIN và tìm kiếm

6.8 Đánh giá thấp chi phí của việc thay đổi kiểu dữ liệu

Vấn đề

• ALTER TABLE có thể rất nặng trên các bảng lớn
• Có thể xảy ra thời gian ngừng dịch vụ hoặc khóa lâu
• Trong một số trường hợp, cần di chuyển dữ liệu

Cách tránh

• Lập kế hoạch cho sự tăng trưởng trong tương lai ngay từ giai đoạn thiết kế
• Sử dụng ENUM một cách cẩn thận
• Để chỗ cho độ chính xác/scale của DECIMAL (nhưng không nên quá mức)

7. Tóm tắt

MySQL cung cấp một loạt các kiểu dữ liệu, và việc lựa chọn kiểu dữ liệu có thể ảnh hưởng đáng kể đến hiệu năng, khả năng mở rộng và khả năng bảo trì.
Đặc biệt trong các môi trường như ứng dụng web, nơi dữ liệu thường tăng trưởng, các quyết định thiết kế sớm sẽ ảnh hưởng trực tiếp đến chất lượng lâu dài.

Những điểm chính trong bài viết này

• Kiểu dữ liệu là yếu tố quan trọng ảnh hưởng đến “loại giá trị, phạm vi, độ chính xác, lưu trữ và hiệu năng.”
• Các kiểu số, chuỗi, ngày/giờ, JSON, ENUM/SET và BLOB đều có ưu và nhược điểm riêng.
• Kiểu số nguyên, chuỗi và ngày/giờ được sử dụng nhiều nhất, vì vậy việc lựa chọn đúng rất quan trọng.
• JSON và ENUM tiện lợi, nhưng sử dụng sai có thể làm cho việc bảo trì trở nên khó khăn.
• Sử dụng quá mức TEXT và BLOB có thể làm giảm hiệu năng.
• Một cách tiếp cận thiết kế hợp lý là: “Mục đích → Phạm vi → Hiệu năng → Khả năng mở rộng.”

Danh sách kiểm tra thiết kế bạn có thể bắt đầu sử dụng ngay hôm nay

• Mục đích của cột có được định nghĩa rõ ràng không?
• Bạn có hiểu giá trị tối đa và tối thiểu có thể có không?
• Có bằng chứng nào hỗ trợ độ dài VARCHAR đã chọn không?
• Bạn có đang sử dụng DECIMAL cho tiền tệ không?
• Các dấu thời gian “updated at” có được quản lý bằng TIMESTAMP và tự động cập nhật khi cần không?
• Trước khi sử dụng ENUM, bạn có cân nhắc rằng các giá trị có thể tăng trong tương lai không?
• Bạn có tránh các thiết kế khiến việc tìm kiếm chậm do lạm dụng JSON không?
• Bạn có thiết kế để tránh các thao tác ALTER TABLE nặng trên các bộ dữ liệu lớn không?

Finally

Không phải lúc nào cũng có một “câu trả lời đúng” duy nhất cho việc chọn kiểu dữ liệu MySQL.
Tuy nhiên, nếu bạn lựa chọn có mục đích và cân nhắc tới sự phát triển trong tương lai, bạn có thể ngăn ngừa các vấn đề lớn và giữ cho cấu trúc dữ liệu của mình sạch sẽ.

Cuối cùng, lựa chọn tốt nhất phụ thuộc vào tính chất dự án, khối lượng dữ liệu và yêu cầu ứng dụng của bạn. Nhưng nếu bạn sử dụng các tiêu chí được giới thiệu trong bài viết này làm nền tảng, bạn sẽ có thể đưa ra các lựa chọn kiểu dữ liệu tốt hơn trong bất kỳ tình huống nào.

Tiếp theo, chúng tôi sẽ giới thiệu một phần FAQ tóm tắt các câu hỏi thường gặp trong công việc thực tế.
Khi bạn không chắc chắn về việc chọn kiểu, việc kiểm tra FAQ này trước sẽ giúp bạn quyết định một cách suôn sẻ hơn.

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

Việc chọn kiểu dữ liệu MySQL là một lĩnh vực mà các quyết định có thể khác nhau đáng kể tùy thuộc vào kinh nghiệm thực tế.
Ở đây chúng tôi tổng hợp các câu hỏi phổ biến từ các nhóm phát triển và cung cấp các câu trả lời ngắn gọn, rõ ràng.

Q1. Tôi nên dùng INT hay BIGINT?

A: Mặc định dùng INT. Chỉ dùng BIGINT nếu có khả năng vượt quá 2,1 tỷ trong tương lai.

INT (4 byte) hỗ trợ tới khoảng 2,1 tỷ và đủ cho hầu hết các ứng dụng.
Xem xét dùng BIGINT cho nhật ký, dịch vụ có lưu lượng cao, hoặc hệ thống có thể phát ra số lượng ID rất lớn.

Q2. Tôi nên dùng VARCHAR hay TEXT?

A: Dùng VARCHAR nếu bạn cần tìm kiếm. Dùng TEXT cho nội dung dài.

• VARCHAR : Thân thiện với chỉ mục và tốt cho việc tìm kiếm
• TEXT : Thích hợp cho nội dung dài nhưng không lý tưởng cho tìm kiếm hoặc JOIN

※ Việc lạm dụng TEXT có thể gây suy giảm hiệu năng.

Q3. Có nên lưu tiền dưới dạng DOUBLE không?

A: Không. Luôn luôn dùng DECIMAL.

DOUBLE và FLOAT có thể gây ra lỗi làm tròn, vì vậy chúng không phù hợp cho tiền tệ hoặc các giá trị yêu cầu độ chính xác cao.
Trong các hệ thống kinh doanh, DECIMAL(10,2) hoặc DECIMAL(12,2) là tiêu chuẩn phổ biến.

Q4. Tôi không hiểu sự khác nhau giữa DATETIME và TIMESTAMP. Tôi nên chọn như thế nào?

A: Dùng TIMESTAMP nếu bạn cần tự động cập nhật. Dùng DATETIME nếu bạn cần lưu một dấu thời gian chính xác mà không có chuyển đổi múi giờ.

• TIMESTAMP : Tự động cập nhật và chuyển đổi múi giờ
• DATETIME : Không bị ảnh hưởng bởi múi giờ; lưu ngày/giờ “nguyên trạng”

DATETIME thường được dùng cho nhật ký và các bảng lịch sử.

Q5. Có an toàn khi sử dụng ENUM không?

A: Nó chỉ hữu ích khi các giá trị “được đảm bảo không thay đổi”.

ENUM nhẹ và tiện lợi, nhưng việc thêm hoặc thay đổi giá trị yêu cầu ALTER TABLE.
Đối với các trường có khả năng mở rộng, quản lý master trong một bảng riêng được khuyến nghị.

Q6. Tôi có thể chỉ dùng JSON ngay bây giờ không?

A: Chỉ dùng JSON cho dữ liệu mà bạn không tìm kiếm. Dữ liệu cần tìm kiếm nên được chuẩn hoá.

JSON linh hoạt, nhưng có những điểm yếu về hiệu năng.

• Yếu trong việc tìm kiếm
• Cấu trúc chỉ mục trở nên phức tạp hơn
• Khó duy trì tính nhất quán dữ liệu

Nó phù hợp cho các cài đặt và tùy chọn — các thuộc tính không được dùng làm điều kiện tìm kiếm.

Q7. Làm sao để quyết định độ dài tối đa cho VARCHAR?

A: Ước tính tối đa dựa trên dữ liệu thực tế và thêm một chút dư thừa.

Ví dụ: Địa chỉ email → VARCHAR(100) là đủ
Ví dụ: Tên người dùng → VARCHAR(50) thường là hợp lý

“255 chỉ vì vậy” không được khuyến khích.

Q8. Nếu tôi chọn sai kiểu, có thể thay đổi sau không?

A: Có, nhưng có thể rất nặng cho các bảng lớn.

ALTER TABLE thường yêu cầu quét toàn bộ và tái tạo lại,
điều này có thể gây thời gian ngừng hoạt động hoặc khóa lâu.

→ Lập kế hoạch cẩn thận ngay từ giai đoạn thiết kế ban đầu là quan trọng nhất.