N+1 Query Problem là gì?

Trong quá trình phát triển Backend, ứng dụng thường cần truy xuất dữ liệu từ database để trả về cho client. Một API có thể cần lấy danh sách đơn hàng cùng thông tin khách hàng tương ứng. Tuy nhiên, nếu ứng dụng truy vấn dữ liệu liên quan riêng lẻ cho từng bản ghi, số lượng truy vấn có thể tăng nhanh khi dữ liệu lớn hơn.

Đây là tình huống thường dẫn đến N+1 Query Problem — một vấn đề hiệu năng phổ biến khi làm việc với database và ORM (Object-Relational Mapping).

1. N+1 Query Problem hoạt động như thế nào?

N+1 Query Problem là vấn đề xảy ra khi ứng dụng thực hiện một truy vấn ban đầu để lấy danh sách dữ liệu, sau đó thực hiện thêm một truy vấn riêng cho mỗi bản ghi nhằm lấy dữ liệu liên quan.

Nếu truy vấn ban đầu trả về (N) bản ghi và ứng dụng thực hiện thêm một truy vấn cho mỗi bản ghi, tổng số truy vấn sẽ là:

[
Q = 1 + N
]

Trong đó:

• (Q): tổng số truy vấn.
• (1): truy vấn ban đầu để lấy danh sách dữ liệu.
• (N): số truy vấn bổ sung để lấy dữ liệu liên quan cho từng bản ghi.

Ví dụ: Lấy danh sách đơn hàng và thông tin khách hàng

Giả sử hệ thống bán hàng có hai bảng orders và customers:

• orders: lưu thông tin đơn hàng, bao gồm id, customer_id và total.
• customers: lưu thông tin khách hàng, bao gồm id, name và email.

Mỗi đơn hàng thuộc về một khách hàng thông qua customer_id.

API cần trả về danh sách đơn hàng kèm tên khách hàng. Một cách triển khai có thể thực hiện như sau:

Bước 1: Lấy danh sách đơn hàng

SELECT id, customer_id, total
FROM orders;

Giả sử truy vấn trả về 100 đơn hàng.

Bước 2: Lấy thông tin khách hàng cho từng đơn hàng

Ứng dụng tiếp tục thực hiện truy vấn tương ứng với từng đơn hàng:

SELECT id, name, email
FROM customers
WHERE id = 1;

SELECT id, name, email
FROM customers
WHERE id = 2;

Các truy vấn trên chỉ mang tính minh họa; trong thực tế, ID khách hàng sẽ phụ thuộc vào dữ liệu của từng đơn hàng.

Nếu ứng dụng thực hiện thêm một truy vấn cho mỗi đơn hàng, tổng số truy vấn sẽ là:

• 1 truy vấn lấy danh sách đơn hàng.
• 100 truy vấn lấy thông tin khách hàng.

Tổng cộng: 101 truy vấn.

Đây chính là N+1 Query Problem. Thay vì lấy dữ liệu cần thiết bằng một số ít truy vấn, ứng dụng thực hiện nhiều truy vấn riêng lẻ để hoàn thành cùng một yêu cầu.

Lưu ý rằng ví dụ trên giả định mỗi đơn hàng phát sinh một truy vấn bổ sung. Nếu nhiều đơn hàng thuộc cùng một khách hàng, ứng dụng vẫn có thể truy vấn lặp lại thông tin khách hàng đó, khiến chi phí truy xuất dữ liệu tăng thêm.

2. Nguyên nhân gây ra N+1 Query Problem

N+1 Query Problem thường xuất phát từ cách ứng dụng truy xuất dữ liệu liên quan giữa các đối tượng hoặc bảng trong database.

2.1. Truy vấn dữ liệu bên trong vòng lặp

Một nguyên nhân phổ biến là thực hiện truy vấn database bên trong vòng lặp để lấy thông tin liên quan cho từng bản ghi.

Ví dụ, về mặt logic, ứng dụng thực hiện:

orders = lấy danh sách đơn hàng

for mỗi order trong orders:
    customer = lấy khách hàng theo order.customer_id
    thêm thông tin customer vào order

Nếu danh sách có 100 đơn hàng và mỗi vòng lặp thực hiện một truy vấn, ứng dụng sẽ tạo ra 100 truy vấn bổ sung.

Vòng lặp không phải lúc nào cũng gây ra vấn đề. Vấn đề nằm ở việc mỗi lần lặp lại phát sinh một truy vấn database riêng lẻ trong khi dữ liệu có thể được lấy theo nhóm.

2.2. Lazy Loading trong ORM

ORM là công cụ ánh xạ dữ liệu quan hệ trong database thành các đối tượng mà chương trình có thể thao tác.

Nhiều ORM hỗ trợ Lazy Loading (tải trì hoãn), nghĩa là dữ liệu liên quan chỉ được tải khi ứng dụng thực sự truy cập đến quan hệ đó.

Ví dụ, ứng dụng lấy danh sách đơn hàng trước. Khi cần hiển thị tên khách hàng của từng đơn hàng, ORM mới truy vấn thông tin khách hàng tương ứng.

Nếu việc truy cập quan hệ này kích hoạt một truy vấn riêng cho mỗi đơn hàng, N+1 Query Problem có thể xảy ra.

Lazy Loading không phải lúc nào cũng xấu. Nó có thể giúp tránh tải dữ liệu không cần thiết. Tuy nhiên, khi được sử dụng không phù hợp trong quá trình xử lý danh sách lớn, nó có thể làm tăng đáng kể số lượng truy vấn.

2.3. Cách ORM tải các quan hệ dữ liệu

Khi làm việc với các quan hệ như một đơn hàng thuộc về một khách hàng hoặc một khách hàng có nhiều đơn hàng, ORM có thể tải dữ liệu theo nhiều cách khác nhau.

Nếu ứng dụng lấy danh sách đơn hàng rồi truy cập quan hệ khách hàng riêng lẻ cho từng đơn hàng, ORM có thể phát sinh nhiều truy vấn.

Ngược lại, nếu ứng dụng chủ động yêu cầu tải trước hoặc tải theo nhóm các quan hệ cần thiết, ORM có thể giảm số lượng truy vấn.

Vì vậy, việc sử dụng ORM không tự động ngăn chặn N+1 Query Problem. Lập trình viên vẫn cần hiểu cách ORM tạo và thực thi SQL khi truy cập dữ liệu.

3. Ảnh hưởng đến hiệu năng

N+1 Query Problem có thể khiến một API hoạt động bình thường khi dữ liệu còn ít nhưng trở nên chậm khi số lượng bản ghi tăng lên.

Tăng số lượng truy vấn

Số truy vấn có thể tăng tuyến tính theo số bản ghi được lấy. Với 100 đơn hàng, ứng dụng có thể thực hiện 101 truy vấn; với 1.000 đơn hàng, con số có thể tăng lên 1.001 truy vấn nếu vẫn sử dụng cùng cách triển khai.

Tăng chi phí giao tiếp giữa Backend và database

Mỗi truy vấn thường cần được gửi đến database và nhận kết quả trả về. Việc thực hiện nhiều truy vấn riêng lẻ làm tăng chi phí giao tiếp, xử lý truy vấn và quản lý kết quả.

Tác động này đặc biệt đáng chú ý khi Backend và database chạy trên các máy chủ khác nhau hoặc có độ trễ mạng đáng kể.

Tăng thời gian phản hồi của API

Ngay cả khi mỗi truy vấn riêng lẻ khá nhanh, tổng thời gian xử lý vẫn có thể tăng do số lượng truy vấn lớn.

Mức độ ảnh hưởng phụ thuộc vào nhiều yếu tố, bao gồm độ trễ mạng, cách thực thi truy vấn, cache, connection pooling và khả năng xử lý đồng thời của database.

Tăng tải cho database

Khi nhiều request đồng thời đều phát sinh hàng trăm hoặc hàng nghìn truy vấn không cần thiết, database phải xử lý nhiều công việc hơn. Điều này có thể làm giảm khả năng phục vụ các request khác và khiến hệ thống khó mở rộng khi lượng người dùng tăng lên.

Tuy nhiên, số lượng truy vấn không phải yếu tố duy nhất quyết định hiệu năng. Một truy vấn phức tạp có thể tốn kém hơn nhiều truy vấn đơn giản. Vì vậy, cần đánh giá cả số lượng truy vấn lẫn chi phí thực thi của chúng.

4. Cách khắc phục N+1 Query Problem

Mục tiêu của việc khắc phục là giảm các truy vấn riêng lẻ không cần thiết, đồng thời chỉ tải dữ liệu mà ứng dụng thực sự cần.

4.1. Sử dụng JOIN

Với ví dụ đơn hàng và khách hàng, có thể dùng JOIN để lấy thông tin từ hai bảng trong cùng một truy vấn:

SELECT
    o.id AS order_id,
    o.total,
    c.id AS customer_id,
    c.name AS customer_name,
    c.email AS customer_email
FROM orders AS o
JOIN customers AS c
    ON o.customer_id = c.id;

Truy vấn này lấy thông tin đơn hàng cùng thông tin khách hàng tương ứng mà không cần thực hiện thêm một truy vấn riêng cho từng đơn hàng.

Đối với ví dụ đang xét, thay vì 101 truy vấn, ứng dụng có thể lấy dữ liệu bằng một truy vấn SQL.

Tuy nhiên, JOIN không phải lúc nào cũng là lựa chọn tốt nhất. Khi kết hợp nhiều quan hệ một-nhiều, kết quả có thể chứa nhiều dòng lặp lại dữ liệu của bảng chính. Vì vậy, cần cân nhắc cấu trúc dữ liệu và hình dạng kết quả mà API cần trả về.

4.2. Sử dụng Batch Loading

Batch Loading (tải dữ liệu theo nhóm) là cách lấy dữ liệu liên quan cho nhiều bản ghi trong một hoặc một số ít truy vấn, thay vì truy vấn riêng lẻ cho từng bản ghi.

Ví dụ, trước tiên lấy danh sách đơn hàng, sau đó lấy thông tin của tất cả khách hàng liên quan bằng IN:

SELECT id, name, email
FROM customers
WHERE id IN (1, 2, 3, 4, 5);

Trong thực tế, danh sách ID sẽ được tạo từ các đơn hàng đã truy xuất và có thể cần chia thành nhiều nhóm nếu dữ liệu quá lớn.

Cách tiếp cận này giúp giảm số truy vấn bổ sung. Thay vì thực hiện một truy vấn cho mỗi đơn hàng, ứng dụng có thể lấy thông tin của nhiều khách hàng trong một lần.

Batch Loading đặc biệt hữu ích khi muốn giữ dữ liệu của các đối tượng riêng biệt trong chương trình mà không cần ghép tất cả dữ liệu thành một tập kết quả lớn như khi dùng JOIN.

4.3. Sử dụng Eager Loading

Eager Loading (tải trước dữ liệu liên quan) là cách yêu cầu ORM tải các quan hệ cần thiết ngay trong quá trình lấy dữ liệu ban đầu, thay vì đợi đến khi từng quan hệ được truy cập.

Tùy ORM và cách cấu hình, Eager Loading có thể sử dụng JOIN, nhiều truy vấn theo nhóm hoặc một cơ chế khác.

Ví dụ về mặt ý tưởng:

orders = lấy danh sách đơn hàng
         đồng thời tải trước thông tin khách hàng

for mỗi order trong orders:
    sử dụng order.customer

Điểm quan trọng là việc truy cập order.customer sau đó không nên làm phát sinh thêm một truy vấn riêng cho từng đơn hàng nếu mục tiêu là tránh N+1.

Tên phương thức và cách triển khai cụ thể phụ thuộc vào ORM được sử dụng. Vì vậy, cần kiểm tra SQL thực tế để xác nhận rằng việc tải trước quan hệ đã giảm số truy vấn như mong đợi.

4.4. Chỉ truy xuất dữ liệu cần thiết

Một cách tối ưu khác là chỉ lấy những cột cần dùng thay vì truy xuất toàn bộ dữ liệu của các bảng.

Ví dụ, nếu API chỉ cần mã đơn hàng, tổng tiền và tên khách hàng, ứng dụng không nhất thiết phải lấy tất cả cột của hai bảng.

SELECT
    o.id,
    o.total,
    c.name
FROM orders AS o
JOIN customers AS c
    ON o.customer_id = c.id;

Việc lựa chọn cột phù hợp giúp giảm lượng dữ liệu được đọc, truyền tải và xử lý. Tuy nhiên, chỉ giảm số cột không tự giải quyết N+1 nếu ứng dụng vẫn thực hiện một truy vấn bổ sung cho từng bản ghi.

Trong thực tế, các biện pháp này có thể được kết hợp với phân trang để tránh tải quá nhiều bản ghi trong một request.

5. Cách phát hiện và kiểm tra N+1 Query Problem

N+1 Query Problem có thể không dễ nhận ra chỉ bằng cách đọc mã nguồn. Một phương pháp đáng tin cậy là quan sát các truy vấn SQL thực sự được ứng dụng thực thi.

5.1. Kiểm tra SQL do ứng dụng phát ra

Bật logging hoặc sử dụng công cụ theo dõi truy vấn của ORM để xem các câu SQL được thực thi khi gọi API.

Nếu nhận thấy ứng dụng thực hiện một truy vấn lấy danh sách, sau đó lặp lại cùng một dạng truy vấn với các giá trị ID khác nhau, đó có thể là dấu hiệu của N+1 Query Problem.

Ví dụ:

SELECT id, customer_id, total
FROM orders;

SELECT id, name
FROM customers
WHERE id = 1;

SELECT id, name
FROM customers
WHERE id = 2;

SELECT id, name
FROM customers
WHERE id = 3;

Nếu mẫu truy vấn thứ hai tiếp tục lặp lại cho hàng trăm đơn hàng, cần xem xét việc tải dữ liệu theo nhóm hoặc tải trước quan hệ.

5.2. Đếm số lượng truy vấn

Có thể kiểm tra số truy vấn được thực thi trong một request API.

Ví dụ, với endpoint lấy danh sách đơn hàng:

• Nếu 10 đơn hàng tạo ra 11 truy vấn và 100 đơn hàng tạo ra 101 truy vấn, đó là dấu hiệu rõ ràng của mô hình N+1 trong trường hợp này.
• Sau khi tối ưu, số truy vấn có thể giảm xuống còn một hoặc một số ít truy vấn, tùy theo phương pháp được sử dụng.

Khi kiểm tra, nên dùng các bộ dữ liệu có kích thước khác nhau. Một endpoint chỉ phát sinh vài truy vấn với một bản ghi chưa chắc hoạt động hiệu quả khi phải xử lý hàng trăm bản ghi.

5.3. Đo thời gian thực thi

Ngoài việc đếm truy vấn, cần đo thời gian phản hồi của API và thời gian thực thi SQL.

Với PostgreSQL, có thể sử dụng EXPLAIN ANALYZE để xem kế hoạch thực thi và thời gian của một câu truy vấn cụ thể. Tuy nhiên, công cụ này chỉ đánh giá câu truy vấn được chạy, không tự động cho biết toàn bộ một request Backend đã thực hiện bao nhiêu truy vấn.

Để kiểm tra N+1 ở cấp ứng dụng, cần kết hợp logging SQL, công cụ giám sát hoặc tracing để xem toàn bộ hoạt động truy xuất dữ liệu trong request.

Sau khi áp dụng biện pháp tối ưu, hãy kiểm tra lại số lượng truy vấn, thời gian phản hồi và tính chính xác của dữ liệu trả về. Mục tiêu không chỉ là giảm số truy vấn mà còn bảo đảm API vẫn hoạt động đúng.

6. Kết luận

N+1 Query Problem là vấn đề hiệu năng thường gặp trong quá trình phát triển Backend, đặc biệt khi ứng dụng truy xuất các quan hệ dữ liệu thông qua vòng lặp hoặc ORM.

Nguyên nhân cốt lõi là ứng dụng thực hiện nhiều truy vấn riêng lẻ cho những dữ liệu có thể được lấy hiệu quả hơn theo nhóm. Điều này làm tăng chi phí giao tiếp giữa Backend và database, kéo dài thời gian phản hồi và có thể tạo thêm tải cho hệ thống khi số lượng bản ghi hoặc request tăng lên.

Để hạn chế vấn đề này, lập trình viên có thể sử dụng JOIN, Batch Loading, Eager Loading và lựa chọn các cột dữ liệu cần thiết. Đồng thời, cần kiểm tra SQL thực tế và đo lường hiệu năng thay vì chỉ dựa vào mã nguồn hoặc giả định rằng ORM sẽ tự tối ưu.

Khi xây dựng API, không chỉ cần quan tâm đến việc truy vấn có trả về đúng dữ liệu hay không, mà còn phải hiểu ứng dụng đang truy xuất dữ liệu bằng bao nhiêu truy vấn và liệu cách truy xuất đó có phù hợp khi dữ liệu tăng lên hay không.

Nguồn tham khảo

• N+1 query và cách phòng tránh

Thanh Tan

Xem tất cả bài viết của tác giả

Bài viết khác

locking & dead lock (Transaction)

1. Locking là gì? Locking (cơ chế khóa) là cơ chế database sử dụng để kiểm soát việc nhiều transaction cùng truy cập hoặc thay đổi dữ liệu, nhằm tránh những xung đột có thể làm sai lệch kết quả. Trong một ứng dụng có nhiều user, nhiều request có thể đồng thời thao tác […]

Đọc thêm

Eloquent ORM

1. Eloquent ORM là gì? Eloquent ORM là ORM được tích hợp sẵn trong Laravel, sử dụng mô hình Active Record để tương tác với database. Eloquent cho phép developer làm việc với dữ liệu thông qua các Model trong PHP thay vì phải viết SQL thủ công cho mọi thao tác. Mỗi model thường […]

Đọc thêm

ORM

ORM là gì? (Object-Relational Mapping) Trong quá trình phát triển Backend, ứng dụng thường xuyên cần tương tác với database để lưu trữ, truy vấn, cập nhật và xóa dữ liệu. Một cách phổ biến để thực hiện những thao tác này là viết SQL trực tiếp. Tuy nhiên, khi dự án phát triển, việc […]

Đọc thêm

UAT(Kiểm thử chấp nhận người dùng)

UAT là gì? Trong toàn bộ Vòng đời phát triển phần mềm (SDLC), sau khi trải qua hàng loạt các cấp độ kiểm thử kỹ thuật nội bộ như Unit Testing, Integration Testing, System Testing, sản phẩm phần mềm vẫn chưa thể chính thức phát hành. Bước đệm cuối cùng và mang tính chất quyết […]

Đọc thêm

Transactions & ACID

Transactions & ACID là gì? Trong Backend, một request gửi đến API có thể yêu cầu hệ thống thực hiện nhiều thao tác trên database. Chẳng hạn, khi khách hàng đặt hàng, hệ thống có thể cần tạo đơn hàng, lưu chi tiết đơn hàng và cập nhật số lượng tồn kho. Nếu một thao […]

Đọc thêm

ORM – Object-Relational Mapping Fundamentals

1. ORM là gì? ORM (Object-Relational Mapping) là kỹ thuật ánh xạ giữa các đối tượng trong chương trình và dữ liệu được lưu trữ trong cơ sở dữ liệu quan hệ. Trong ứng dụng backend, dữ liệu thường được biểu diễn bằng struct hoặc object trong code, trong khi database lưu dữ liệu dưới […]

Đọc thêm