INNER JOIN sâu: nhiều bảng, multiple conditions

Mở đầu — vì sao bài này quan trọng

Ở Bài 2 bạn đã làm quen với INNER JOIN ở mức cơ bản: ghép hai bảng lại với nhau dựa trên một cột khóa chung. Đó là bước khởi đầu tốt, nhưng trong công việc thực tế của một Business Analyst, dữ liệu hiếm khi nằm gọn trong hai bảng. Một câu hỏi tưởng chừng đơn giản như "doanh thu tháng trước đến từ những khách hàng ở thành phố nào, mua sản phẩm thuộc danh mục gì, qua kênh marketing nào?" có thể buộc bạn phải nối 4–5 bảng cùng lúc.

Đây chính là lằn ranh phân biệt một người "biết viết SQL" với một người "dùng SQL để trả lời câu hỏi nghiệp vụ". Khi bạn join nhiều bảng, mỗi điều kiện nối sai một chút là con số báo cáo lệch đi — và điều nguy hiểm là query vẫn chạy, vẫn ra kết quả, chỉ là kết quả sai. Sếp nhìn vào dashboard, ra quyết định dựa trên con số đó, và không ai biết nó sai cho đến khi quá muộn.

Bài này tập trung sâu vào INNER JOIN: cách nối từ ba bảng trở lên một cách có kỷ luật, cách dùng nhiều điều kiện trong mệnh đề ON, và cách tránh những cái bẫy khiến con số phình to hoặc co lại bất ngờ. Chúng ta để dành LEFT/RIGHT/FULL OUTER JOIN cho bài sau — ở đây bạn sẽ làm chủ hoàn toàn loại join "chặt chẽ" nhất.

Khái niệm cốt lõi

Nhắc lại bản chất của INNER JOIN

INNER JOIN chỉ trả về những dòng có giá trị khớp ở cả hai bảng. Nếu một đơn hàng tham chiếu đến một customer_id không tồn tại trong bảng customers, đơn hàng đó sẽ biến mất khỏi kết quả. Đây là đặc tính quan trọng nhất bạn phải khắc cốt ghi tâm: INNER JOIN âm thầm loại bỏ dữ liệu không khớp. Nó không báo lỗi, không cảnh báo — chỉ lặng lẽ bỏ qua.

Về mặt khái niệm, hãy hình dung INNER JOIN tạo ra phần giao của hai tập hợp. Database lấy mỗi dòng ở bảng A, tìm tất cả các dòng ở bảng B thỏa điều kiện ON, rồi ghép chúng thành các dòng kết quả. Nếu không tìm thấy dòng B nào khớp, dòng A đó bị loại.

Nối ba bảng trở lên: cơ chế dây chuyền

Khi nối nhiều bảng, SQL xử lý theo kiểu dây chuyền tuần tự. Bạn có thể hình dung như sau: kết quả của join thứ nhất tạo thành một "bảng trung gian" tạm thời, rồi join thứ hai sẽ nối bảng tiếp theo vào bảng trung gian đó, cứ thế tiếp tục.

SELECT
  o.id          AS order_id,
  c.full_name   AS customer_name,
  p.name        AS product_name,
  oi.quantity,
  oi.unit_price
FROM orders o
INNER JOIN customers c   ON o.customer_id = c.id
INNER JOIN order_items oi ON oi.order_id  = o.id
INNER JOIN products p     ON oi.product_id = p.id;

Đọc query trên theo trình tự: bắt đầu từ orders, nối với customers để biết ai đặt hàng, rồi nối với order_items để lấy từng dòng sản phẩm trong đơn, cuối cùng nối với products để lấy tên sản phẩm. Mỗi mệnh đề ON nói rõ "ghép theo cột nào".

Một điều cực kỳ quan trọng: mỗi INNER JOIN thêm vào đều là một bộ lọc tiềm ẩn. Nếu một đơn hàng có dòng order_items trỏ tới một product_id đã bị xóa khỏi bảng products, thì khi join tới products, dòng đó sẽ rớt. Càng nối nhiều bảng, càng nhiều cơ hội để dữ liệu bị loại bỏ ngoài ý muốn.

Alias bảng — không phải để cho đẹp

Bạn thấy o, c, oi, p ở trên chứ? Đó là alias (bí danh) của bảng. Khi nối nhiều bảng, alias không còn là tùy chọn cho gọn nữa mà là điều bắt buộc về mặt thực hành. Nhiều bảng có cùng tên cột (id, name, created_at), nên nếu không ghi rõ o.id hay c.id, database sẽ báo lỗi "ambiguous column" — cột mơ hồ, không biết bạn muốn cột nào. Hãy đặt alias ngắn gọn nhưng gợi nhớ, và luôn đặt tiền tố cho mọi cột khi join từ hai bảng trở lên.

Nhiều điều kiện trong ON

Mệnh đề ON không bị giới hạn ở một điều kiện bằng nhau. Bạn có thể ghép nhiều điều kiện bằng AND:

FROM orders o
INNER JOIN promotions pr
  ON pr.product_id = o.product_id
  AND o.order_date BETWEEN pr.start_date AND pr.end_date

Ở đây ta nối đơn hàng với khuyến mãi, nhưng chỉ khi sản phẩm khớp và ngày đặt hàng nằm trong thời gian khuyến mãi có hiệu lực. Đây là pattern cực kỳ phổ biến với dữ liệu có yếu tố thời gian: một sản phẩm có thể có nhiều đợt khuyến mãi khác nhau, và bạn chỉ muốn ghép đúng đợt áp dụng cho thời điểm mua.

Phân biệt điều kiện ở ON và ở WHERE

Với INNER JOIN, đặt điều kiện lọc ở ON hay ở WHERE thường cho cùng kết quả — đây là điểm khác biệt lớn so với LEFT JOIN (sẽ học ở bài sau, nơi vị trí điều kiện thay đổi hoàn toàn kết quả). Tuy nhiên, dù kết quả giống nhau, tôi khuyên bạn nên phân biệt theo ý nghĩa: đặt điều kiện ghép nối (cách hai bảng liên kết với nhau) vào ON, và đặt điều kiện lọc nghiệp vụ (lọc theo trạng thái, thời gian, vùng miền) vào WHERE. Cách này giúp query dễ đọc và dễ chuyển sang LEFT JOIN sau này mà không sinh lỗi logic.

Tình huống thực tế

Tình huống 1: Báo cáo doanh thu theo danh mục ở Tiki

Giả sử bạn là BA tại một sàn thương mại điện tử kiểu Tiki. Phòng kinh doanh hỏi: "Tháng 5/2026, mỗi đơn hàng đã giao thành công gồm những sản phẩm nào, thuộc danh mục gì, và giá trị từng dòng là bao nhiêu?" Dữ liệu nằm rải ở bốn bảng: orders (đơn hàng), order_items (chi tiết từng sản phẩm trong đơn), products (sản phẩm), và categories (danh mục).

SELECT
  o.id                          AS order_id,
  cat.name                      AS category_name,
  p.name                        AS product_name,
  oi.quantity,
  oi.unit_price,
  oi.quantity * oi.unit_price   AS line_total
FROM orders o
INNER JOIN order_items oi ON oi.order_id   = o.id
INNER JOIN products p     ON p.id          = oi.product_id
INNER JOIN categories cat ON cat.id        = p.category_id
WHERE o.status = 'delivered'
  AND o.order_date >= '2026-05-01'
  AND o.order_date <  '2026-06-01';

Diễn giải: Ta đi từ orders, "nổ" ra từng dòng sản phẩm qua order_items, lấy thông tin sản phẩm rồi truy ngược lên danh mục. Điều kiện lọc nghiệp vụ — trạng thái đã giao và khoảng thời gian tháng 5 — nằm gọn ở WHERE. Lưu ý cách viết khoảng ngày: >= '2026-05-01' AND < '2026-06-01' an toàn hơn BETWEEN khi cột có cả phần giờ, vì nó bao trọn ngày 31/5 đến 23:59:59.

Bài học rút ra: Khi đơn hàng có nhiều sản phẩm, join với order_items khiến một đơn hàng trở thành nhiều dòng kết quả. Đây gọi là quan hệ một-nhiều và nó hoàn toàn đúng đắn ở mức chi tiết dòng (line-item). Nhưng nếu sếp hỏi "có bao nhiêu đơn hàng?", bạn không được đếm số dòng — phải đếm COUNT(DISTINCT o.id). Nhầm chỗ này là sai số kinh điển của BA mới.

Tình huống 2: Ghép khuyến mãi đúng thời điểm tại một chuỗi F&B

Một chuỗi trà sữa giả định tên "Phúc Trà" chạy nhiều chương trình giảm giá theo từng giai đoạn. Bảng bills ghi mỗi hóa đơn, bảng bill_items ghi từng món, và bảng promotions ghi các đợt khuyến mãi theo sản phẩm kèm khoảng thời gian hiệu lực. Câu hỏi: "Trong các hóa đơn, món nào được mua đúng vào lúc đang có khuyến mãi áp dụng?"

SELECT
  b.id              AS bill_id,
  b.created_at,
  bi.product_id,
  pr.campaign_name,
  pr.discount_percent
FROM bills b
INNER JOIN bill_items bi
  ON bi.bill_id = b.id
INNER JOIN promotions pr
  ON pr.product_id = bi.product_id
  AND b.created_at >= pr.start_date
  AND b.created_at <  pr.end_date;

Diễn giải: Điều then chốt nằm ở mệnh đề ON cuối cùng có ba điều kiện: khớp sản phẩm, và thời điểm tạo hóa đơn phải nằm trong cửa sổ khuyến mãi. Vì dùng INNER JOIN, kết quả chỉ chứa những món thực sự rơi vào một đợt khuyến mãi đang chạy — món nào mua ngoài thời gian khuyến mãi sẽ bị loại bỏ, đúng như mong muốn.

Bài học rút ra: INNER JOIN ở đây đóng vai trò vừa nối vừa lọc cùng lúc. Nếu một sản phẩm có hai đợt khuyến mãi chồng thời gian (lỗi cấu hình thường gặp), một món mua sẽ khớp với cả hai dòng promotions và nhân đôi kết quả. Là BA, khi thấy con số "số món khuyến mãi" cao bất thường, hãy nghi ngờ việc trùng đợt khuyến mãi trước tiên.

Tình huống 3: Phân tích chuyến đi ride-hailing kiểu Be/Grab

Bạn phân tích cho một nền tảng gọi xe. Phòng vận hành muốn biết: mỗi chuyến đi hoàn thành thuộc về tài xế nào, khách nào, và xuất phát từ khu vực nào. Dữ liệu ở trips, drivers, riders, và zones (vùng địa lý).

SELECT
  t.id            AS trip_id,
  d.full_name     AS driver_name,
  r.full_name     AS rider_name,
  z.zone_name     AS pickup_zone,
  t.fare
FROM trips t
INNER JOIN drivers d ON d.id = t.driver_id
INNER JOIN riders r  ON r.id = t.rider_id
INNER JOIN zones z   ON z.id = t.pickup_zone_id
WHERE t.status = 'completed'
  AND t.completed_at >= '2026-06-01';

Diễn giải: Đây là dạng "star join" điển hình — một bảng trung tâm (trips) nối ra nhiều bảng tra cứu (lookup) xung quanh. Mỗi chuyến đi có đúng một tài xế, một khách, một vùng đón, nên đây là các quan hệ nhiều-một, và số dòng kết quả không bị "nổ" thêm.

Bài học rút ra: Nếu một số chuyến đi tự dưng biến mất khỏi báo cáo, thủ phạm thường là INNER JOIN với một bảng có dữ liệu thiếu — ví dụ pickup_zone_id bị NULL vì GPS lỗi lúc đón khách. Vì NULL không khớp với bất kỳ giá trị nào trong ON, những chuyến đó bị loại sạch. Lúc này bạn sẽ cần LEFT JOIN (bài sau), nhưng quan trọng là bạn phải nhận ra dữ liệu đang bị thiếu — đối chiếu tổng số chuyến trước và sau khi join là thói quen sống còn.

Hướng dẫn từng bước

Khi xây dựng một query nối nhiều bảng, hãy theo quy trình kỷ luật sau thay vì viết tất cả một lúc:

Xác định bảng trung tâm. Câu hỏi nghiệp vụ xoay quanh "đơn hàng", "chuyến đi" hay "giao dịch"? Bảng đó là điểm xuất phát ở FROM.

Vẽ sơ đồ quan hệ trên giấy. Ghi ra các cột khóa: orders.customer_id nối tới customers.id, v.v. Mười phút vẽ tay tiết kiệm hàng giờ debug.

Bắt đầu nhỏ — chỉ hai bảng. Viết và chạy join đầu tiên, kiểm tra số dòng có hợp lý không. Đừng viết một mạch 5 bảng rồi mới chạy.

Thêm từng bảng một, chạy lại sau mỗi lần. Sau mỗi INNER JOIN, để ý số dòng kết quả thay đổi ra sao. Nếu số dòng tăng vọt bất ngờ, bạn vừa gặp quan hệ một-nhiều ngoài dự kiến. Nếu số dòng giảm, bạn vừa lọc mất dữ liệu do không khớp.

Đặt alias rõ ràng và tiền tố mọi cột ngay từ đầu, đừng để cuối cùng mới sửa.

Tách điều kiện đúng chỗ: điều kiện ghép nối vào ON, điều kiện lọc nghiệp vụ vào WHERE.

Đối chiếu với một con số đã biết. Nếu báo cáo nội bộ nói tháng 5 có 12.400 đơn đã giao, thì COUNT(DISTINCT o.id) của bạn phải khớp con số đó. Lệch là dấu hiệu join đang thêm hoặc bớt dữ liệu.

Lỗi thường gặp & mẹo

Đếm sai do quan hệ một-nhiều. Sau khi join orders với order_items, mỗi đơn nhiều dòng. Dùng COUNT(*) để đếm "số đơn" sẽ cho ra "số dòng sản phẩm" — phình to gấp nhiều lần. Luôn dùng COUNT(DISTINCT o.id) khi muốn đếm thực thể gốc.

Nhân bản dữ liệu (fan-out) khi join hai bảng một-nhiều cùng lúc. Nếu bạn nối orders với cả order_items lẫn payments (mỗi đơn nhiều dòng thanh toán), số dòng sẽ là tích của hai phía — một đơn có 3 sản phẩm và 2 lần thanh toán cho ra 6 dòng. Mọi phép SUM sau đó đều bị thổi phồng. Mẹo: gom (aggregate) một bên trong subquery hoặc CTE trước khi join, đừng nối hai quan hệ một-nhiều trực tiếp với nhau.

Quên điều kiện ON — sinh ra tích Descartes (cross join). Nếu lỡ viết thiếu mệnh đề ON, hoặc dùng dấu phẩy FROM a, b mà quên điều kiện ở WHERE, mỗi dòng bảng A ghép với mọi dòng bảng B. 10.000 dòng nhân 10.000 dòng thành 100 triệu dòng — query treo, hoặc tệ hơn, ra kết quả sai mà vẫn chạy. Luôn kiểm tra mỗi join đều có ON đầy đủ.

Quên ý nghĩa lọc của INNER JOIN. Mỗi bảng nối thêm có thể âm thầm loại dòng do NULL hoặc dữ liệu mồ côi. Mẹo: chạy COUNT(*) trước và sau khi thêm mỗi join để phát hiện ngay khi nào dữ liệu bắt đầu rơi rớt.

Lỗi "ambiguous column". Khi hai bảng có cột trùng tên mà bạn không đặt tiền tố, database từ chối chạy. Mẹo phòng ngừa: tiền tố mọi cột bằng alias ngay từ dòng đầu tiên, biến nó thành thói quen.

Mẹo về thứ tự join và hiệu năng. Với INNER JOIN, thứ tự bạn viết các bảng thường không đổi kết quả vì bộ tối ưu hóa của database tự sắp xếp lại. Nhưng về mặt đọc hiểu, hãy đặt bảng trung tâm trước rồi nối dần các bảng tra cứu — query sẽ dễ theo dõi hơn nhiều.

Bài tập thực hành

Giả sử bạn có các bảng: orders(id, customer_id, status, order_date), order_items(id, order_id, product_id, quantity, unit_price), products(id, name, category_id), categories(id, name), customers(id, full_name, city).

Cơ bản: Viết query liệt kê order_id, tên khách hàng, tên sản phẩm và số lượng cho mọi đơn hàng có status = 'delivered'. Nối đủ các bảng cần thiết và đặt alias rõ ràng.

Nhiều điều kiện ON: Cho thêm bảng promotions(product_id, start_date, end_date, discount_percent). Viết query tìm các dòng order_items được mua trong khi sản phẩm đang có khuyến mãi (so order_date với khoảng start_date–end_date).

Tránh đếm sai: Viết query đếm số đơn hàng riêng biệt có chứa sản phẩm thuộc danh mục "Đồ uống". Chú ý dùng COUNT(DISTINCT ...) cho đúng.

Suy ngẫm: Chạy query ở câu 1 với và không có điều kiện join tới customers. Số dòng có khác nhau không? Nếu có, điều đó nói lên gì về dữ liệu khách hàng bị thiếu trong bảng orders?

Nâng cao: Viết query trả về mỗi danh mục cùng tổng doanh thu (SUM(quantity * unit_price)) từ các đơn đã giao trong quý 2/2026. Suy nghĩ xem cần GROUP BY cột nào.

Tóm tắt

INNER JOIN là công cụ nối dữ liệu chặt chẽ nhất: nó chỉ giữ những dòng khớp ở mọi bảng, và âm thầm loại bỏ phần còn lại. Khi nối từ ba bảng trở lên, hãy hình dung quá trình như một dây chuyền tuần tự, trong đó mỗi join vừa ghép dữ liệu vừa đóng vai một bộ lọc tiềm ẩn. Mệnh đề ON có thể chứa nhiều điều kiện ghép bằng AND, đặc biệt hữu ích cho dữ liệu có yếu tố thời gian như khuyến mãi.

Ba nguyên tắc bạn nên mang theo: luôn đặt alias và tiền tố mọi cột; phân biệt điều kiện ghép nối (ON) với điều kiện lọc nghiệp vụ (WHERE); và luôn đối chiếu số dòng trước/sau mỗi join để bắt sớm hai cái bẫy lớn nhất — đếm sai do quan hệ một-nhiều, và mất dữ liệu do dòng không khớp. Khi bạn xây query theo từng bước nhỏ và kiểm chứng bằng con số đã biết, bạn không chỉ viết được SQL đúng mà còn tự tin bảo vệ con số trước mặt sếp. Ở bài tiếp theo, ta sẽ mở rộng sang LEFT/RIGHT/FULL OUTER JOIN để giữ lại đúng phần dữ liệu mà INNER JOIN đã loại bỏ.