1. Tổng quan về hiệu năng cơ sở dữ liệu

Hiệu năng cơ sở dữ liệu ảnh hưởng trực tiếp đến thời gian phản hồi API, độ trễ hệ thống, và tốc độ truy cập người dùng. Một truy vấn chậm 500ms có thể nhân lên hàng trăm nghìn lần khi hệ thống mở rộng.

Nguyên tắc cốt lõi: “Query ít hơn, dữ liệu trả về nhỏ hơn, và CPU/IO hoạt động ít hơn.”

Việc tối ưu cần thực hiện trên 4 tầng:

1. Tầng cấu trúc dữ liệu (Schema Design)
2. Tầng truy vấn (Query Optimization)
3. Tầng lưu trữ và hạ tầng (Storage & Hardware)
4. Tầng cache và phân vùng (Caching & Partitioning)

2. Thiết kế schema hợp lý

Thiết kế schema là bước đầu tiên quyết định hiệu năng dài hạn.

2.1. Chuẩn hóa và phi chuẩn hóa (Normalization vs Denormalization)

• **Chuẩn hóa (Normalization)**: giảm trùng lặp dữ liệu, tăng tính toàn vẹn. Phù hợp với OLTP (ứng dụng giao dịch nhỏ, nhiều ghi).
• **Phi chuẩn hóa (Denormalization)**: gộp bảng hoặc lưu dữ liệu lặp lại để giảm số lượng JOIN. Phù hợp với OLAP (báo cáo, phân tích, dashboard).

Kinh nghiệm: bắt đầu với chuẩn hóa (3NF), sau đó phi chuẩn hóa từng phần khi gặp bottleneck thực tế.

2.2. Lựa chọn kiểu dữ liệu tối ưu

• Chọn INT thay vì BIGINT nếu ID dưới 2 tỷ.
• Dùng VARCHAR với độ dài vừa đủ, tránh TEXT trừ khi cần thiết.
• Ưu tiên kiểu DATE, DATETIME hoặc TIMESTAMP thay vì lưu chuỗi.
• Trong MongoDB, nên tránh lưu document quá 16MB và tách subdocument hợp lý.

2.3. Ràng buộc và chỉ mục

Đặt constraint (PRIMARY KEY, FOREIGN KEY, UNIQUE) giúp kiểm soát dữ liệu, đồng thời hỗ trợ query planner chọn đường chạy tối ưu.

3. Index – Linh hồn của hiệu năng truy vấn

Index giúp truy vấn nhanh hơn, nhưng lạm dụng lại gây phản tác dụng vì tốn RAM và chậm khi ghi dữ liệu.

3.1. Các loại index phổ biến

• B-Tree Index: mặc định trong hầu hết DB (MySQL, PostgreSQL). Tốt cho so sánh, range query.
• Hash Index: cho so sánh chính xác (=), nhưng không hỗ trợ ORDER BY hoặc range.
• GIN / GiST Index: cho dữ liệu JSONB hoặc full-text search trong PostgreSQL.
• Composite Index: kết hợp nhiều cột, chỉ có tác dụng nếu query lọc theo thứ tự cột trong index.

3.2. Chiến lược sử dụng index

• Chỉ tạo index trên các cột thường xuyên được lọc (WHERE) hoặc JOIN.
• Tránh index trên cột có độ phân tán thấp (ví dụ: boolean, giới tính).
• Kiểm tra bằng EXPLAIN ANALYZE (Postgres) hoặc EXPLAIN (MySQL) để biết index có được dùng không.

3.3. Cân nhắc chi phí ghi (write cost)

Mỗi index thêm vào làm chậm thao tác INSERT/UPDATE. Với bảng log hoặc event tracking, nên giảm số lượng index tối đa.

4. Tối ưu truy vấn (Query Optimization)

• Chỉ chọn cột cần thiết: SELECT field1, field2 thay vì SELECT *.
• Dùng LIMIT và OFFSET hoặc pagination theo ID để tránh scan toàn bảng.
• Tránh sử dụng hàm trong điều kiện WHERE vì sẽ vô hiệu hóa index (WHERE DATE(created_at) = '2025-10-01' nên thay bằng range query).
• Dùng CTE (Common Table Expressions) hoặc subquery hợp lý, nhưng tránh lồng nhau quá nhiều tầng.
• Trong MongoDB, dùng projection để loại bỏ field không cần thiết.

Luôn kiểm tra execution plan để xác định bottleneck thực tế.

5. Caching – Tầng tăng tốc bắt buộc

Caching giúp giảm truy vấn DB lặp lại. Có 3 loại phổ biến:

• Query cache: lưu kết quả truy vấn.
• Object cache: lưu dữ liệu sau khi ORM xử lý.
• Materialized view: trong PostgreSQL hoặc MongoDB Aggregation Pipeline để lưu dữ liệu tóm tắt.

Dùng Redis hoặc Memcached để cache dữ liệu tạm thời, với TTL (time-to-live) phù hợp.

6. Phân vùng (Partitioning) và chia nhỏ dữ liệu (Sharding)

6.1. Partitioning

Chia bảng lớn thành nhiều phần nhỏ (ví dụ: theo tháng hoặc năm). Giúp query nhanh hơn khi chỉ cần đọc dữ liệu theo range thời gian.

• PostgreSQL hỗ trợ PARTITION BY RANGE hoặc HASH.
• MongoDB hỗ trợ shard key theo field định trước.

6.2. Sharding

Chia dữ liệu theo chiều ngang (horizontal scaling) sang nhiều node khác nhau. Phù hợp cho hệ thống lớn như social network, analytics.

Chiến lược chọn shard key cần cẩn thận — nếu chọn sai, sẽ dẫn đến “hot shard”. Nên chọn trường có độ phân tán đều, ví dụ user_id thay vì region.

7. Giám sát và bảo trì cơ sở dữ liệu

• Giám sát qua pg_stat_statements (Postgres) hoặc performance_schema (MySQL).
• Dọn dẹp bảng log, archive dữ liệu cũ theo thời gian.
• Rebuild index định kỳ để tránh phân mảnh (fragmentation).
• Giám sát slow query log để phát hiện bottleneck thực tế.
• Sử dụng APM (New Relic, Datadog, Prometheus + Grafana) để theo dõi metric.

8. Checklist tối ưu thực tế

• Thiết kế schema rõ ràng, tránh join không cần thiết.
• Tạo index hợp lý, kiểm tra bằng EXPLAIN plan.
• Sử dụng cache ở nhiều tầng (Redis, CDN, ứng dụng).
• Phân vùng dữ liệu lớn theo thời gian hoặc key.
• Giới hạn kích thước batch insert/update.
• Giám sát và đo lường thường xuyên, tránh tối ưu mù quáng.

Kết luận

Tối ưu cơ sở dữ liệu không phải là một thao tác tức thời, mà là một chiến lược dài hạn gắn liền với toàn bộ vòng đời phát triển ứng dụng. Một hệ thống hiệu năng cao luôn bắt đầu bằng việc hiểu sâu về dữ liệu, thiết kế đúng ngay từ đầu, và liên tục đo đạc để điều chỉnh.

Khi được thực hiện đúng cách, bạn có thể giảm 80% độ trễ truy vấn, giảm 50% tải CPU và tăng khả năng mở rộng gấp nhiều lần — mà không cần tăng thêm tài nguyên phần cứng.