title: "AI for Database Schema Design: Dùng AI thiết kế ERD và tối ưu query (Indexing/Partitioning)"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 1 — AI-Native Coding & Tooling"
order: 9
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "13 phút"
tags: ["database", "schema-design", "erd", "indexing", "partitioning", "sql", "ai-native", "query-optimization"]

AI for Database Schema Design: Dùng AI thiết kế ERD và tối ưu query (Indexing/Partitioning)

Một bảng bookings được thiết kế với guest_name, guest_email, guest_phone nhét thẳng vào bảng đặt phòng — vì "lúc đó chưa nghĩ tới việc một khách đặt nhiều lần". Sáu tháng sau, sản phẩm cần tính năng "lịch sử khách hàng", "khách VIP đặt trên 5 lần", "gộp thông tin khách trùng số điện thoại". Không thể làm được gì trong số đó mà không viết một migration backfill dữ liệu từ hàng trăm nghìn dòng bookings sang một bảng guests mới, xử lý trùng lặp, xử lý dữ liệu bẩn (số điện thoại nhập sai định dạng ở ba kiểu khác nhau), và làm tất cả trong lúc hệ thống production vẫn đang nhận booking mới.

Đây là lý do lỗi thiết kế schema là loại lỗi đắt nhất trong toàn bộ vòng đời một hệ thống. Một bug logic trong service có thể sửa bằng một PR, deploy lại, xong. Một schema sai — thiếu chuẩn hóa hợp lý ở chỗ cần, hoặc chuẩn hóa quá mức ở chỗ không cần, thiếu index đúng chỗ ngay từ ngày đầu — không sửa bằng một PR được. Nó đụng tới dữ liệu đã tồn tại, đụng tới mọi query đang chạy trên bảng đó, và thường chỉ lộ ra khi dữ liệu đã đủ lớn để câu query chậm rõ rệt — tức là khi chi phí sửa đã cao nhất.

AI không tự động cứu bạn khỏi lỗi này. Nhưng nó thay đổi được một thứ quan trọng: chi phí để "hỏi ý kiến thứ hai" trước khi chốt schema, hoặc để phân tích một query pattern thực tế trước khi thêm index, giờ gần như bằng không. Bài này nói về cách dùng AI đúng chỗ ở hai giai đoạn khác nhau của vòng đời database — thiết kế ban đầu và tối ưu khi đã chạy thật — và ranh giới rõ ràng mà một Solutions Architect phải biết để không biến AI thành cái cớ bỏ qua việc đo đạc thực tế.

Vấn đề

Ba lý do khiến schema thiết kế sai lọt qua giai đoạn đầu và trở thành nợ kỹ thuật đắt giá:

1. Chuẩn hóa (normalization) là một quyết định có đánh đổi, không phải một quy tắc đúng/sai. Sách giáo khoa dạy 3NF như một chuẩn mực, nhưng thực chiến thì "chuẩn hóa đúng mức" phụ thuộc vào query pattern thực tế: một bảng report đọc nhiều — ghi ít có thể phi chuẩn hóa (denormalize) một phần để tránh JOIN tốn kém; một bảng giao dịch tài chính cần chuẩn hóa chặt để tránh anomaly khi update. Developer mới hoặc dưới áp lực deadline thường chọn một hướng cực đoan — hoặc nhét mọi thứ vào một bảng cho nhanh, hoặc tách bảng quá mức theo lý thuyết mà không tính chi phí JOIN — mà không có ai đóng vai trò phản biện về đánh đổi đó tại thời điểm thiết kế.

2. Index là con dao hai lưỡi, và tác động của nó không hiện ra ngay. Thiếu index đúng chỗ làm query chậm — điều này dễ thấy khi dữ liệu đủ lớn. Nhưng thừa index, hoặc index sai loại, làm chậm write path (INSERT/UPDATE/DELETE phải cập nhật thêm mọi index liên quan) — điều này thường không ai để ý cho đến khi throughput ghi dữ liệu trở thành bottleneck, và lúc đó ít ai nghĩ "có khi tại index".

3. Partitioning và các quyết định scale được cân nhắc quá muộn. Một bảng log hoặc bảng event tăng vài triệu dòng mỗi tháng thường được thiết kế như một bảng bình thường ở ngày đầu — vì lúc đó dữ liệu còn ít, mọi query đều nhanh. Đến khi bảng đạt hàng chục triệu dòng, full table scan bắt đầu chậm, backup/restore mất hàng giờ, và lúc này việc thêm partitioning vào một bảng đang production, đang có traffic, khó hơn rất nhiều so với thiết kế partitioning key ngay từ đầu.

Điểm chung của cả ba: chúng đều là quyết định rẻ để làm đúng lúc đầu, đắt để sửa sau. Đây chính xác là loại quyết định nên tận dụng AI để có thêm góc nhìn phản biện — không phải để AI quyết định thay bạn, mà để AI buộc bạn phải nêu rõ đánh đổi trước khi chốt.

Kỹ thuật cốt lõi

Kỹ thuật này chia làm hai giai đoạn tách biệt, dùng AI theo cách khác nhau ở mỗi giai đoạn:

flowchart TD
    A["Giai đoạn 1: Thiết kế ban đầu<br/>(chưa có dữ liệu thật)"] --> A1["Input: mô tả nghiệp vụ"]
    A1 --> A2["AI đề xuất: bảng, PK/FK, quan hệ<br/>+ giải thích đánh đổi normalize/denormalize"]
    A2 --> A3["Con người review, chốt schema"]
    A3 --> A4["Migration tạo bảng"]
    A4 --> B["Hệ thống chạy thật,<br/>tích luỹ dữ liệu + traffic"]
    B --> B1["Input: query pattern thực tế<br/>(EXPLAIN, slow query log)"]
    B1 --> B2["AI đề xuất: index phù hợp<br/>+ đánh giá cần partitioning?"]
    B2 --> B3["Đo đạc trên staging<br/>(EXPLAIN trước/sau)"]
    B3 --> B4["Áp dụng qua migration,<br/>giám sát write latency"]

    style A2 fill:#59c,stroke:#333,stroke-width:1px
    style B2 fill:#c55,stroke:#333,stroke-width:1px

Giai đoạn 1 — thiết kế ERD: AI hữu ích nhất khi đóng vai "đồng nghiệp phản biện" — bạn mô tả nghiệp vụ, AI đề xuất cấu trúc bảng kèm giải thích lý do, không chỉ đưa ra một schema chốt. Giá trị thật không nằm ở việc AI "vẽ đúng ERD" — mà ở việc nó liệt kê được các phương án khác nhau (ví dụ: tách Rates thành bảng riêng hay nhét vào Rooms) và nêu rõ đánh đổi của từng phương án, để bạn ra quyết định có ý thức thay vì mặc định theo thói quen.

Giai đoạn 2 — tối ưu khi đã chạy: đây là lúc AI không thể tự suy luận được nếu thiếu dữ liệu thật. AI không biết query nào chạy thường xuyên, bảng nào có bao nhiêu dòng, cardinality của cột nào cao hay thấp — trừ khi bạn cung cấp. Kỹ thuật đúng là: đưa AI câu SQL chậm thật + kết quả EXPLAIN thật (hoặc mô tả schema + ước lượng số dòng), để nó phân tích execution plan cụ thể thay vì đoán chung chung "thêm index vào cột WHERE là được".

Sự khác biệt cốt lõi giữa hai giai đoạn: giai đoạn 1 AI làm việc tốt với thông tin trừu tượng (mô tả nghiệp vụ), giai đoạn 2 AI chỉ đáng tin khi có dữ liệu thực tế cụ thể làm input. Nhầm lẫn giữa hai giai đoạn — ví dụ hỏi AI "nên thêm index gì" mà không đưa query pattern thật — là nguồn gốc của phần lớn cạm bẫy sẽ nói ở cuối bài.

Thực hành

Giai đoạn 1: Prompt thiết kế ERD từ mô tả nghiệp vụ

Ví dụ: thiết kế schema cho một hệ thống đặt phòng (booking system) đơn giản, gồm các khái niệm Rooms, Bookings, Guests, Rates.

Bạn là một Database Architect. Tôi cần thiết kế schema cho một hệ thống đặt phòng
(booking system) trên MySQL 8. Mô tả nghiệp vụ:

- Một khách sạn có nhiều loại phòng (Room Type: Standard, Deluxe, Suite...),
  mỗi loại có nhiều phòng vật lý cụ thể (Room), mỗi phòng có số phòng riêng.
- Giá phòng (Rate) thay đổi theo mùa/ngày trong tuần/loại phòng — một loại phòng
  có thể có nhiều mức giá áp dụng cho các khoảng ngày khác nhau.
- Khách (Guest) có thể đặt phòng (Booking) nhiều lần, mỗi lần đặt có ngày
  check-in/check-out, số lượng khách, trạng thái (pending/confirmed/cancelled/completed).
- Một Booking có thể gồm nhiều phòng (đặt 2 phòng Deluxe cùng lúc là 1 booking).
- Cần truy vấn nhanh: (a) phòng nào còn trống trong khoảng ngày X-Y,
  (b) lịch sử đặt phòng của một khách, (c) doanh thu theo loại phòng theo tháng.
- Hệ thống dự kiến 50 khách sạn, mỗi khách sạn ~100 phòng, ~50 booking/ngày/khách sạn.

Yêu cầu:
1. Đề xuất danh sách bảng, với tên cột chính, kiểu dữ liệu, primary key, foreign key.
2. Với MỖI quyết định thiết kế có nhiều hơn một phương án hợp lý (ví dụ: Rate là
   bảng riêng hay cột trong Room; RoomType có tách riêng hay nhét vào Room),
   nêu RÕ ít nhất 2 phương án, phân tích đánh đổi chuẩn hóa (normalize) vs
   phi chuẩn hóa (denormalize) cho từng phương án — không chỉ chốt một đáp án.
3. Chỉ ra các cột nên có index ngay từ đầu dựa trên 3 truy vấn (a)(b)(c) ở trên,
   và giải thích ngắn gọn vì sao (không cần EXPLAIN vì chưa có dữ liệu thật).
4. Vẽ sơ đồ quan hệ dạng Mermaid erDiagram.
5. Chỉ rõ ràng buộc toàn vẹn dữ liệu quan trọng (ví dụ: không cho phép 2 booking
   trùng phòng trùng khoảng ngày — đề xuất cách enforce ở tầng DB hoặc ứng dụng).

Không cần viết migration SQL đầy đủ, chỉ cần thiết kế schema + giải thích.

Vì sao prompt này hiệu quả (không phải chỉ hỏi "thiết kế schema cho hệ thống đặt phòng"):

• Mô tả nghiệp vụ đủ cụ thể để AI không phải đoán — bao gồm cả con số quy mô dự kiến (50 khách sạn, ~50 booking/ngày), vì "chuẩn hóa đúng mức" phụ thuộc trực tiếp vào scale.
• Yêu cầu tường minh (2): buộc AI trình bày đánh đổi thay vì chỉ đưa một đáp án — đây là phần giá trị nhất, vì bạn cần hiểu tại sao, không chỉ cần một ERD để copy.
• Yêu cầu (5) về ràng buộc toàn vẹn: đây là chỗ AI hay bỏ sót nếu không hỏi thẳng — ví dụ overlap booking là một constraint nghiệp vụ tinh vi, không tự nhiên xuất hiện trong một ERD generate hời hợt.

Ví dụ output rút gọn (minh hoạ định dạng trả lời nên có, không phải bảng chốt cuối cùng để copy nguyên xi vào production):

Phương án Rate:
A. Bảng `rates` riêng: room_type_id, start_date, end_date, price, day_of_week (nullable)
   - Ưu: linh hoạt thêm mùa giá mới không cần sửa schema, truy vấn lịch sử giá dễ.
   - Nhược: JOIN thêm 1 bảng mỗi khi tính giá cho một booking.
B. Nhét price vào bảng room_type, đổi giá bằng cách update trực tiếp:
   - Ưu: query nhanh hơn (không JOIN), đơn giản.
   - Nhược: MẤT lịch sử giá — booking cũ sẽ hiển thị sai giá nếu giá đổi sau đó
     (đây là vi phạm nghiêm trọng cho một hệ thống cần audit doanh thu theo tháng).

=> Khuyến nghị: Phương án A, vì yêu cầu (c) "doanh thu theo loại phòng theo tháng"
   đòi hỏi tra cứu giá tại THỜI ĐIỂM booking, không phải giá hiện tại — bảng rates
   riêng là bắt buộc, không phải tuỳ chọn.

erDiagram
    ROOM_TYPE ||--o{ ROOM : "có nhiều"
    ROOM_TYPE ||--o{ RATE : "áp dụng giá theo"
    ROOM ||--o{ BOOKING_ROOM : "được đặt trong"
    BOOKING ||--o{ BOOKING_ROOM : "gồm nhiều phòng"
    GUEST ||--o{ BOOKING : "thực hiện"

    ROOM_TYPE {
        bigint id PK
        varchar name
        int max_occupancy
    }
    ROOM {
        bigint id PK
        bigint room_type_id FK
        varchar room_number
        bigint hotel_id FK
    }
    RATE {
        bigint id PK
        bigint room_type_id FK
        date start_date
        date end_date
        decimal price
    }
    GUEST {
        bigint id PK
        varchar full_name
        varchar phone
        varchar email
    }
    BOOKING {
        bigint id PK
        bigint guest_id FK
        date check_in
        date check_out
        enum status
    }
    BOOKING_ROOM {
        bigint booking_id FK
        bigint room_id FK
        decimal price_at_booking
    }

Chú ý cột price_at_booking trong bảng nối BOOKING_ROOM — đây là một dạng phi chuẩn hóa có chủ đích (lưu snapshot giá tại thời điểm đặt), khác với việc JOIN sang bảng RATE để lấy giá hiện tại. Một AI review tốt sẽ giải thích rõ đây không phải trùng lặp dữ liệu vô nghĩa mà là yêu cầu nghiệp vụ (giá đã đặt không đổi dù rate sau đó thay đổi).

Giai đoạn 2: Prompt tối ưu index từ một query chậm thật

Giả sử sau vài tháng chạy production, câu query sau đây (tìm phòng trống cho một khách sạn trong khoảng ngày, lọc theo loại phòng) đang chạy chậm khi bảng booking_room đã có ~2 triệu dòng:

SELECT r.id, r.room_number, rt.name AS room_type_name
FROM rooms r
JOIN room_types rt ON rt.id = r.room_type_id
WHERE r.hotel_id = 42
  AND rt.max_occupancy >= 2
  AND r.id NOT IN (
    SELECT br.room_id
    FROM booking_room br
    JOIN bookings b ON b.id = br.booking_id
    WHERE b.status IN ('confirmed', 'pending')
      AND b.check_in < '2026-08-20'
      AND b.check_out > '2026-08-15'
  );

Prompt tối ưu:

Câu SQL sau đang chạy chậm (MySQL 8, InnoDB) — thời gian thực thi ~3.2 giây
trên bảng bookings (~500k dòng), booking_room (~2 triệu dòng), rooms (~5,000 dòng),
room_types (~50 dòng):

[DÁN CÂU SQL Ở TRÊN VÀO ĐÂY]

Đây là kết quả EXPLAIN hiện tại:

[DÁN OUTPUT CỦA "EXPLAIN ANALYZE <query>" VÀO ĐÂY]

Yêu cầu:
1. Phân tích execution plan hiện tại — chỉ ra bước nào đang gây chậm nhất
   (full scan? filesort? dependent subquery?).
2. Đề xuất index cụ thể (tên bảng, tên cột, thứ tự cột trong composite index)
   để cải thiện câu query này. Với MỖI index đề xuất, giải thích:
   - Vì sao thứ tự cột đó (liên hệ tới điều kiện WHERE/JOIN nào).
   - Ảnh hưởng ước tính tới tốc độ ghi (write) của bảng đó — bảng bookings
     và booking_room có tốc độ ghi khoảng 2,000 booking mới/ngày.
3. Nếu có cách viết lại query hiệu quả hơn (ví dụ thay NOT IN bằng NOT EXISTS
   hoặc LEFT JOIN ... IS NULL) mà giữ nguyên kết quả, đề xuất kèm giải thích.
4. Không đề xuất index cho cột có cardinality thấp (ví dụ status chỉ có
   3-4 giá trị) đứng một mình — chỉ đề xuất nếu kết hợp trong composite index
   có ích.

Chỉ đề xuất, không tự cho là đúng — tôi sẽ chạy EXPLAIN ANALYZE lại trên
staging với dữ liệu thật trước khi áp dụng production.

Ba chi tiết khiến prompt này khác biệt với "làm sao để query này nhanh hơn":

• Đưa cả EXPLAIN thật, không chỉ câu SQL — đây là dữ liệu AI không thể tự có, và không có nó thì mọi đề xuất index chỉ là đoán dựa trên cấu trúc câu SQL (vẫn có ích, nhưng kém chính xác hơn nhiều).
• Yêu cầu tường minh về ảnh hưởng tới write path (mục 2) — buộc AI cân nhắc đánh đổi đọc/ghi thay vì chỉ tối ưu một chiều.
• Kết thúc bằng cam kết tự đo lại — đặt đúng vai trò của AI: đề xuất có căn cứ, không phải quyết định cuối cùng.

Output kỳ vọng sẽ đề xuất dạng: CREATE INDEX idx_booking_room_dates ON bookings (hotel_id, status, check_in, check_out) (composite index đặt cột lọc bằng trước, cột range sau) kèm giải thích vì sao thứ tự đó tối ưu cho MySQL range scan, và cảnh báo rằng nếu bookings có insert rate cao, thêm quá nhiều composite index chồng chéo sẽ làm chậm insert — nên ưu tiên 1-2 index phục vụ đúng query pattern thường gặp nhất thay vì index "phòng hờ" cho mọi trường hợp.

Khi nào nên cân nhắc partitioning

Nguyên tắc chung: partitioning giải quyết vấn đề vận hành trên bảng lớn (backup, xoá dữ liệu cũ, DDL) tốt hơn là vấn đề tốc độ một câu query đơn lẻ — nếu vấn đề chỉ là một query chậm, thường index đúng đã đủ giải quyết trước khi cần tính đến partitioning.

Cạm bẫy thường gặp

1. Áp dụng mù quáng mọi đề xuất index của AI mà không đo bằng EXPLAIN. AI có thể đề xuất một index nghe hợp lý về mặt cú pháp (khớp với cột trong WHERE) nhưng không tối ưu về thứ tự cột, hoặc trùng lặp với index đã có (MySQL có thể tự dùng một phần của index composite sẵn có mà không cần index mới). Luôn chạy EXPLAIN ANALYZE trước và sau khi thêm index trên staging với dữ liệu có volume gần giống production — không phải trên bảng test 100 dòng, vì optimizer chọn plan khác nhau tùy vào cardinality thật.

2. Thêm index sai chỗ làm chậm ghi mà không ai để ý cho đến khi throughput ghi tăng. Mỗi index thêm vào là một cấu trúc B-tree phải cập nhật đồng bộ với mọi INSERT/UPDATE/DELETE trên bảng đó. Một bảng có tốc độ ghi cao (ví dụ bảng event log, bảng audit) mà có 6-7 index để phục vụ đủ loại báo cáo sẽ chịu write amplification đáng kể — điều này thường bị bỏ qua vì hiệu ứng chỉ rõ khi traffic ghi đã lớn, lúc đó việc gỡ index sai đã khó vì không rõ báo cáo nào đang phụ thuộc vào nó. Luôn hỏi "index này phục vụ query nào, tần suất bao nhiêu, và tốc độ ghi hiện tại của bảng là bao nhiêu" trước khi thêm.

3. AI không biết pattern truy vấn thực tế nếu bạn không cung cấp — và nó sẽ không tự nói "tôi đang đoán". Nếu bạn hỏi AI "bảng này nên có index gì" mà chỉ đưa CREATE TABLE, không đưa query pattern thật (query nào chạy thường xuyên nhất, tần suất, volume dữ liệu), AI vẫn trả lời tự tin — dựa trên suy luận hợp lý từ tên cột và kiểu ràng buộc (unique, foreign key), chứ không phải từ dữ liệu vận hành thật. Kết quả có thể đúng một phần nhưng bỏ sót đúng cái quan trọng nhất: query nào đang thực sự làm hệ thống chậm. Luôn cung cấp slow query log hoặc EXPLAIN thật khi ở giai đoạn tối ưu — đừng để AI đoán thay cho việc đo đạc.

🧭 Góc nhìn Solutions Architect
Khi AI đề xuất một schema hoặc một index, bạn có đang chấp nhận nó vì nó "nghe hợp lý", hay vì bạn đã đối chiếu với query pattern thật (EXPLAIN, slow query log) và volume dữ liệu dự kiến ở quy mô production, không phải quy mô demo? Với một quyết định schema khó đảo ngược — như chọn khóa chính là UUID hay auto-increment, hay quyết định denormalize một trường — bạn có đang dành đủ thời gian cân nhắc đánh đổi dài hạn, hay đang để tốc độ prototype của AI cám dỗ bạn chốt schema sớm hơn mức nên chốt?

🔗 Bài viết liên quan

• AI & Legacy Code: đọc hiểu và tài liệu hoá — kỹ thuật dùng AI đọc hiểu schema/code cũ, hữu ích khi schema hiện tại đã là di sản cần cải tổ dần thay vì viết lại.
• Refactoring with AI: hướng tới Clean Architecture — nguyên tắc tái cấu trúc có kiểm soát, áp dụng được khi cần sửa schema đã sai mà không phá vỡ hệ thống đang chạy.

Bài trước: Security & Code Scanning · Bài tiếp theo: Custom AI Tools