Câu hỏi phỏng vấn SQL & Database thường gặp (kèm gợi ý trả lời)

1. 01Phân biệt INNER JOIN, LEFT JOIN, RIGHT JOIN và FULL OUTER JOIN. Khi nào dùng LEFT JOIN?Junior

   Gợi ý trả lời

   JOIN quyết định giữ lại những dòng nào khi ghép hai bảng theo điều kiện.

   • INNER JOIN: chỉ giữ dòng khớp ở cả hai bảng.
   • LEFT JOIN: giữ mọi dòng bảng trái; bảng phải không khớp thì cột thành NULL.
   • RIGHT JOIN: ngược lại với LEFT, ít dùng vì có thể đổi chỗ bảng.
   • FULL OUTER JOIN: giữ tất cả dòng của cả hai (MySQL không hỗ trợ trực tiếp, phải UNION hai LEFT JOIN).

   Ví dụ tìm khách chưa từng đặt hàng:

   SELECT c.id, c.name
   FROM customers c
   LEFT JOIN orders o ON o.customer_id = c.id
   WHERE o.id IS NULL;
   

   Hay sai: đặt điều kiện lọc bảng phải trong WHERE (vd. WHERE o.status = 'paid') làm LEFT JOIN biến thành INNER JOIN; điều kiện đó phải để trong ON.

2. 02WHERE và HAVING khác nhau thế nào? Thứ tự thực thi logic của một câu SELECT ra sao?Junior

   Gợi ý trả lời

   WHERE lọc từng dòng trước khi gom nhóm; HAVING lọc sau GROUP BY, nên dùng được hàm tổng hợp như COUNT, SUM.

   Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT/OFFSET.

   SELECT department_id, AVG(salary) AS avg_salary
   FROM employees
   WHERE status = 'active'
   GROUP BY department_id
   HAVING AVG(salary) > 20000000;
   

   • Vì SELECT chạy sau WHERE, bạn không dùng được alias của SELECT trong WHERE (đa số DB).
   • Điều kiện không cần hàm tổng hợp thì nên để ở WHERE để giảm số dòng phải gom nhóm.

   Người phỏng vấn muốn nghe: bạn hiểu thứ tự logic, từ đó giải thích được vì sao alias hoặc aggregate dùng sai chỗ bị lỗi.

3. 03Index là gì, hoạt động thế nào? Có nên đánh index cho mọi cột không?Junior

   Gợi ý trả lời

   Index là cấu trúc dữ liệu phụ (thường là B-Tree) giúp tìm dòng theo giá trị cột mà không phải quét cả bảng, đổi lại tốn dung lượng và làm chậm thao tác ghi.

   • B-Tree hợp với so sánh =, <, >, BETWEEN, ORDER BY, LIKE 'abc%'.
   • Mỗi INSERT/UPDATE/DELETE phải cập nhật thêm mọi index liên quan.
   • Cột có độ chọn lọc thấp (vd. gender, is_deleted) đánh index riêng thường ít tác dụng.

   Không nên đánh index tràn lan: chỉ thêm cho cột hay xuất hiện trong WHERE, JOIN, ORDER BY của các query quan trọng, rồi kiểm tra bằng EXPLAIN.

   Hay sai: bọc cột trong hàm, vd. WHERE YEAR(created_at) = 2026 hoặc LOWER(email) = ..., khiến index thường trên cột đó không được dùng. Hãy viết lại thành khoảng thời gian hoặc dùng index trên biểu thức.

4. 04Transaction là gì? Giải thích ACID.Junior

   Gợi ý trả lời

   Transaction là một nhóm thao tác được thực hiện như một đơn vị: hoặc tất cả thành công (COMMIT), hoặc không có gì xảy ra (ROLLBACK).

   • Atomicity: không có trạng thái làm dở dang.
   • Consistency: sau transaction dữ liệu vẫn thoả ràng buộc (khoá ngoại, unique, check).
   • Isolation: các transaction chạy đồng thời không thấy dữ liệu dở dang của nhau, mức độ tuỳ isolation level.
   • Durability: đã commit thì không mất dù server sập (nhờ write-ahead log / redo log).

   BEGIN;
   UPDATE accounts SET balance = balance - 500 WHERE id = 1;
   UPDATE accounts SET balance = balance + 500 WHERE id = 2;
   COMMIT;
   

   Người phỏng vấn muốn nghe: một ví dụ thực tế như chuyển tiền hoặc trừ tồn kho, và bạn biết giữ transaction ngắn, không gọi API bên ngoài khi đang mở transaction.

5. 05Composite index (index nhiều cột) hoạt động ra sao? Thứ tự cột có quan trọng không?

   Gợi ý trả lời

   Có. Composite index sắp xếp theo cột đầu, rồi đến cột thứ hai trong cùng giá trị cột đầu, v.v. Vì vậy nó chỉ dùng hiệu quả khi query dùng các cột từ trái sang (leftmost prefix).

   Với INDEX (status, created_at):

   • WHERE status = 'paid' AND created_at > ...: dùng tốt.
   • WHERE status = 'paid' ORDER BY created_at DESC: dùng cho cả lọc lẫn sắp xếp.
   • WHERE created_at > ... (không có status): thường không dùng được.

   Nguyên tắc chọn thứ tự: cột so sánh bằng (=) đặt trước, cột so sánh khoảng hoặc sắp xếp đặt sau. Nếu index chứa đủ mọi cột query cần (covering index) thì DB không phải đọc lại bảng.

   Hay sai: tạo riêng index cho từng cột rồi nghĩ rằng chúng sẽ kết hợp hiệu quả như một composite index.

6. 06Các isolation level là gì? Dirty read, non-repeatable read, phantom read khác nhau thế nào?

   Gợi ý trả lời

   Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

   • Dirty read: đọc dữ liệu transaction khác chưa commit.
   • Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
   • Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

   Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

   Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

   Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

7. 07Một API chạy chậm, nghi do query. Bạn điều tra và tối ưu thế nào?

   Gợi ý trả lời

   Đo trước rồi mới sửa: tìm đúng query chậm, đọc execution plan, rồi chỉnh index hoặc cách viết query.

   1. Bật slow query log (MySQL) hoặc pg_stat_statements (PostgreSQL) để biết query nào tốn thời gian nhất.
   2. Chạy EXPLAIN (PostgreSQL nên dùng EXPLAIN (ANALYZE, BUFFERS)) xem có full scan, ước lượng số dòng lệch nhiều so với thực tế, sort trên đĩa không.
   3. Sửa theo nguyên nhân: thêm hoặc đổi composite index, bỏ hàm bọc cột, chỉ SELECT cột cần, phân trang bằng keyset thay cho OFFSET lớn.
   4. Kiểm tra phía ứng dụng: lỗi N+1 query, thiếu connection pool, lock chờ lâu.
   5. Cập nhật thống kê (ANALYZE) nếu planner ước lượng sai.

   Người phỏng vấn muốn nghe: quy trình có số liệu trước/sau, không phải đoán rồi thêm index bừa.

8. 08Chuẩn hoá (normalization) là gì? Khi nào nên denormalize?

   Gợi ý trả lời

   Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

   • 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
   • 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
   • 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

   Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

   Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

9. 09Deadlock trong database xảy ra thế nào và xử lý ra sao?Senior

   Gợi ý trả lời

   Deadlock là khi hai transaction giữ khoá mà bên kia cần và chờ nhau mãi. DB tự phát hiện, chọn một transaction làm nạn nhân và rollback nó.

   Ví dụ: T1 khoá dòng A rồi muốn B, cùng lúc T2 khoá B rồi muốn A.

   Cách giảm deadlock:

   • Luôn khoá tài nguyên theo cùng một thứ tự (vd. sắp xếp theo id trước khi update nhiều dòng).
   • Giữ transaction ngắn, không chờ I/O bên ngoài khi đang giữ khoá.
   • Có index phù hợp để câu UPDATE/DELETE không khoá quá nhiều dòng.
   • Ứng dụng bắt lỗi deadlock và retry có giới hạn.

   Khi điều tra: MySQL dùng SHOW ENGINE INNODB STATUS, PostgreSQL xem log (deadlock được ghi kèm câu lệnh) và pg_locks.

   Người phỏng vấn muốn nghe: bạn coi retry là bình thường nhưng vẫn tìm gốc rễ ở thứ tự khoá.

10. 10Khi nào chọn NoSQL (MongoDB, Redis…) thay vì SQL? Trade-off là gì?Senior

    Gợi ý trả lời

    Chọn theo mô hình truy cập dữ liệu, không theo xu hướng. SQL mạnh ở quan hệ, ràng buộc và transaction; NoSQL mạnh ở schema linh hoạt, mô hình dữ liệu đặc thù hoặc scale ngang dễ hơn.

    • Document (MongoDB): dữ liệu dạng cây, đọc nguyên khối theo một khoá, schema thay đổi thường xuyên.
    • Key-value (Redis): cache, session, rate limit, bộ đếm, hàng đợi nhỏ; dữ liệu chủ yếu nằm trong RAM.
    • Wide-column, time-series, search engine: ghi khối lượng lớn, log, tìm kiếm full-text.

    Trade-off: JOIN và transaction nhiều document hạn chế hoặc đắt hơn, ràng buộc dữ liệu chuyển sang tầng ứng dụng, và phải thiết kế theo query ngay từ đầu.

    Người phỏng vấn muốn nghe: nhiều hệ thống dùng kết hợp, vd. PostgreSQL làm nguồn sự thật, Redis làm cache. PostgreSQL với JSONB cũng đủ cho nhiều nhu cầu "schema linh hoạt".

11. 11Bảng có hàng trăm triệu dòng, query ngày càng chậm. Bạn dùng partitioning, sharding hay read replica?Senior

    Gợi ý trả lời

    Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

    • Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
    • Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
    • Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

    Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

    Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

12. 12Làm sao migrate schema (thêm cột, đổi kiểu, thêm index) trên bảng lớn mà không downtime?Senior

    Gợi ý trả lời

    Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

    1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
    2. Code mới ghi vào cả cột cũ và mới.
    3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
    4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
    5. Contract: bỏ cột cũ ở một lần deploy sau.

    Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

    Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

Gặp câu hỏi khác khi phỏng vấn? Kể lại ẩn danh để người sau ôn đúng trọng tâm, hoặc xem câu hỏi thật hay gặp ở nhiều công ty.