ThisWeb
資深前端工程師
發佈/更新於
和 2000+ 工程師一起學習軟體、AI 開發技巧，每週一收穫 1 篇技術內容、1 段職涯分享、1 個最新資訊！
N+1 問題是後端領域中非常常見、也非常重要的效能議題。
假設我們現在要查 10 篇貼文的內容以及前 5 則留言。
你會怎麼做呢？
如果我們先查一次主資料
然後再用迴圈跑 10 次，每次再查留言：
這樣總共會執行 11 次查詢（1 次查主資料，外加 10 次查留言）。
當資料量很小時，看起來好像還可以接受，但如果查詢量變大，例如需要查詢 10,000 篇貼文，那就會造成 10,001 次查詢，效能會呈線性成長，甚至造成資料庫負載暴增。
而且現實場景通常更複雜，例如我們還要查每個留言的作者，又需要再跑一次迴圈：
總共會經歷：
一不小心就會變成 N x M 問題了。
而且這很容易不小心出現在有使用 ORM 的情況，因爲 ORM 的設計理念就是讓我們像操作物件一樣的去操作資料，所以會把查詢包裝得像普通函式呼叫，大家就會比較容易忽略查詢帶來的花費。
比如上面的例子，如果用 Prisma ORM 來寫就會類似這樣：
核心方法其實非常單純，就是將分散的查詢合併為少數幾次查詢。
我們可以藉由以下方式做到：
當需要同時查詢多張資料表時，可以用 JOIN 一次把所有資料組合起來，避免一筆筆查詢關聯資料。
這樣只需要一次查詢，就能取得貼文與留言的完整資料。
如果只需要查某一張表（例如留言），可以利用 IN 一次查回所有相關資料，而不是為每個 post 個別執行查詢。
簡單來說：
同時主動載入關聯資料
許多 ORM 預設採用 Lazy Loading，也就是遇到關聯資料時才會在背後發出查詢，這往往是造成 N+1 問題的主因。
以 Prisma 為例，可以利用 include 同步取回所有需要的資料：
這樣 ORM 會自動批次查詢，避免每筆資料都產生額外的查詢。
最後總結一下，如果我們在關聯資料查詢中，採用以下模式：
就會產生典型的 N+1 問題。
這類問題在資料量變大時，就會照成效能上的問題。
解法的核心，是避免在迴圈中查資料，改用 JOIN、IN 查詢或 ORM 的 eager loading，做查詢批次化，直接把資料一次帶回。
SELECT * FROM posts LIMIT 10;SELECT * FROM comments WHERE post_id = ? LIMIT 5;SELECT * FROM users WHERE id = ?;SELECT
p.*,
c.*
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE p.id IN (SELECT id FROM posts LIMIT 10);SELECT * FROM comments WHERE post_id IN (SELECT id FROM posts LIMIT 10);const posts = await prisma.post.findMany({
take: 10,
include: {
comments: true,
},
});const posts = await prisma.post.findMany();
for (const post of posts) {
const comments = await prisma.comment.findMany({
where: { postId: post.id },
});
for (const comment of comments) {
const user = await prisma.user.findUnique({
where: { id: comment.userId },
});
}
}