N+1 সমস্যা — include, select আর query মাপা

১ · লুপের ভেতরে লুকানো ৪১টি query

একটি রেস্তোরাঁর কথা ভাবুন। ওয়েটার ২০ টেবিলের অর্ডার খাতায় লিখলেন। এবার প্রতিটি টেবিলের ভাত আনতে একবার রান্নাঘরে গেলেন, ফিরলেন, আবার ডালের জন্য গেলেন। ২০ টেবিলে ৪০ বার হাঁটা। অথচ একবারে পুরো তালিকা নিয়ে গেলে একটি যাত্রাতেই কাজ হতো। রান্না ধীর নয়, যাতায়াতই সময় খাচ্ছে।

N+1 ঠিক এই হাঁটা: তালিকার জন্য ১টি query, তারপর তালিকার প্রতিটি সারির জন্য আরও query. পর্ব ৩৬-এ (GraphQL) resolver-এর ভেতরে এটি দেখেছেন, আর DataLoader দিয়ে কমিয়েছেন। এই পর্ব ORM-এর দিক থেকে দেখে। SQL join-এর তত্ত্ব আছে DBMS কোর্সের join পর্বে.

বাজারঘরের admin পাতায় সবশেষ ২০টি অর্ডার দেখাতে হবে, প্রতিটিতে ক্রেতার নাম আর পণ্যের তালিকা। একজন নতুন developer Prisma-তে সবচেয়ে সরল পথে লিখলেন:

export async function listOrdersLoop(take: number) {
  const orders = await prisma.order.findMany({ take, orderBy });
  const out = [];
  for (const o of orders) {
    const customer = await prisma.customer.findUnique({ where: { id: o.customerId } });
    const items = await prisma.orderItem.findMany({ where: { orderId: o.id } });
    out.push({ ...o, customer, items });
  }
  return out;
}

কোড পড়তে পরিষ্কার, type-ও ঠিক, ছোট ডেটায় দ্রুতও। এবার চালিয়ে দেখি। এই পর্বের সব মাপ একটি আসল project থেকে এসেছে: Prisma 7.10.1, PostgreSQL 18.6 (npm-এর বহনযোগ্য embedded-postgres দিয়ে), Node.js 24.15. লেখার সময়ে npm-এর latest tag ছিল 8.0.0-rc.29, একটি release candidate, তাই আমরা শেষ stable 7.10.1 ইচ্ছা করে বেছে নিয়েছি। Seed করা ডেটা: ১,০০০ ক্রেতা, ২,০০০ পণ্য, ১,০০,০০০ অর্ডার, ৩,০০,০০০ অর্ডার-সারি।

import 'dotenv/config';
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from './generated/prisma/client.js';

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
export const prisma = new PrismaClient({
  adapter,
  log: [{ emit: 'event', level: 'query' }],   // প্রতিটি SQL একটি event
});
prisma.$on('query', (e) => console.log(e.duration, e.query, e.params));

সত্যিকারের run · একটি local কম্পিউটারে · প্রথম ৫টি লাইন, বাকি ৩৬টি ছাঁটা · সময় গোল করা, "public". বাদ · ~/bazarghar

29.9ms SELECT "t0"."id", "t0"."status", "t0"."total", "t0"."createdAt", "t0"."customerId" FROM "Order" AS "t0" ORDER BY "t0"."createdAt" DESC, "t0"."id" DESC LIMIT $1 ["20"]
 0.3ms SELECT "t0"."id", "t0"."name", "t0"."city" FROM "Customer" AS "t0" WHERE ("t0"."id" = $1 AND 1=1) LIMIT $2 [1,"1"]
15.9ms SELECT "t0"."id", "t0"."qty", "t0"."price", "t0"."orderId", "t0"."productId" FROM "OrderItem" AS "t0" WHERE "t0"."orderId" = $1 [100000]
 0.6ms SELECT "t0"."id", "t0"."name", "t0"."city" FROM "Customer" AS "t0" WHERE ("t0"."id" = $1 AND 1=1) LIMIT $2 [82,"1"]
27.7ms SELECT "t0"."id", "t0"."qty", "t0"."price", "t0"."orderId", "t0"."productId" FROM "OrderItem" AS "t0" WHERE "t0"."orderId" = $1 [99999]
…
loop (N+1)   queries= 41   759.0 ms

একই আকৃতির SQL বারবার, শুধু parameter বদলাচ্ছে। Log-এ N+1 চেনার চিহ্ন এটাই। নিচে তিনটি অর্ডারে ছোট করে একই ঘটনা দেখুন।

1orders = await order.findMany({ take: 3 })2for (const o of orders) {3  await customer.findUnique(o.customerId)4  await orderItem.findMany(o.id)5}6return out

২ · include আর select — একবারে আনা, যতটুকু দরকার ততটুকু

সমাধানের প্রথম ধাপ include: “অর্ডারের সাথে এই সম্পর্কগুলোও আনুন।” গভীরে যেতে include-এর ভেতরে আরেকটি include বসে। ক্রেতা, পণ্য আর পণ্যের ক্যাটাগরি একসাথে:

// nested include: অর্ডার → সারি → পণ্য → ক্যাটাগরি
const orders = await prisma.order.findMany({
  take: 20, orderBy,
  include: {
    customer: true,
    items: { include: { product: { include: { category: true } } } },
  },
});

লুপ চলে গেল, SQL সংখ্যা আর N-এর ওপর নির্ভর করে না। কিন্তু include প্রতিটি টেবিলের সব কলাম আনে। আমাদের Product.description প্রায় ২–৩ KB লম্বা, অথচ admin পাতায় লাগে শুধু পণ্যের নাম। একে বলে over-fetching. দর্জির কাছে শুধু হাতার মাপ চেয়ে পুরো গায়ের মাপ নেওয়ার মতো, কাজ হয়, সময় আর কাপড় নষ্ট হয়। সমাধান select:

const orders = await prisma.order.findMany({
  take: 20, orderBy,
  select: {
    id: true, total: true, status: true,
    customer: { select: { name: true } },
    items: { select: { qty: true, product: { select: { name: true } } } },
  },
});

সত্যিকারের run · একটি local কম্পিউটারে · ৯ বার (১,০০০ অর্ডারে ৫ বার) চালিয়ে মধ্যমা · পুরো JSON.stringify-এর byte · relationJoins flag চালু · ২০ অর্ডারের সারিতে ক্যাটাগরিও আনা হয়েছে, ১,০০০ অর্ডারের সারিতে নয় · সাধারণ ফল নয়

২০টি অর্ডারে পার্থক্য ১৫০,১৬০ ÷ ৬,৪৩৭ ≈ ২৩ গুণ. ১,০০০ অর্ডারে ৭,৩৭৩,৭৪২ ÷ ২০২,১৫৫ ≈ ৩৬ গুণ. লক্ষ করুন, SQL সংখ্যা সব সারিতে ১, অথচ খরচ আলাদা। তাই query গোনা যথেষ্ট নয়, কত ডেটা আসছে সেটিও দেখতে হবে। আর এই খরচ শেষে ক্রেতার মোবাইল ডেটায় পড়ে। পাতায় যত ঘর দেখাবেন, API-তে ততটুকুই আনুন।

৩ · দুই relation load strategy — join বনাম query

include ভেতরে দুভাবে চলতে পারে। Prisma-তে একে বলে relationLoadStrategy. query মানে টেবিলপ্রতি একটি SQL, আর জোড়া লাগানোর কাজ অ্যাপে। join মানে একটিমাত্র SQL, যেখানে PostgreSQL LATERAL JOIN দিয়ে JSON বানিয়ে দেয়। MySQL-এ correlated subquery ব্যবহার হয়।

generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["relationJoins"]
}

prisma.order.findMany({
  take: 20, orderBy,
  relationLoadStrategy: 'join',   // অথবা 'query'
  include: { customer: true, items: true },
});

orders = findMany({ take: 20, include: { customer, items } })
// ফল: [{ id, status, ..., customer: {...}, items: [...] }]

SELECT "Order"."id", … FROM "Order" WHERE 1=1
ORDER BY "Order"."createdAt" DESC, "Order"."id" DESC
LIMIT $1 OFFSET $2                 ["20","0"]

SELECT … FROM "Customer" WHERE "Customer"."id"
  IN ($1,$2,…,$20)       [1,82,163,…]
SELECT … FROM "OrderItem" WHERE "OrderItem"."orderId"
  IN ($1,$2,…,$20)       [100000,99999,…]

customerId → customer   (২০টি অর্ডারের সাথে)
orderId    → items[]    (৬০টি সারি ভাগ করে)
database-এ join হয়নি, Node-এ হলো

SELECT "t0"."id", …,
  "Order_customer"."__prisma_data__" AS "customer",
  "Order_items"."__prisma_data__" AS "items"
FROM "Order" AS "t0"
LEFT JOIN LATERAL (SELECT JSONB_BUILD_OBJECT('id', … )
  FROM "Customer" AS "t1"
  WHERE "t0"."customerId" = "t1"."id" LIMIT $1) … ON true
LEFT JOIN LATERAL (SELECT COALESCE(JSONB_AGG(…), '[]')
  … WHERE "t0"."id" = "t2"."orderId" …) … ON true
ORDER BY "t0"."createdAt" DESC, "t0"."id" DESC LIMIT $2

Limit (rows=20)
  Nested Loop Left Join
    Index Scan using "Order_createdAt_id_idx" (rows=20)
    Index Scan using "Customer_pkey" (loops=20)
    Index Scan using "OrderItem_orderId_idx" (loops=20)
Execution Time: 0.585 ms

শেষ কথাটি সংখ্যায় দেখুন। নিচে একই পাতা, index ছাড়া আর index সহ। (Index কীভাবে বেছেছি, তা ৮ নম্বর অংশে।)

সত্যিকারের run · একটি local কম্পিউটারে, network ছাড়া · ৯ বার চালিয়ে মধ্যমা · সাধারণ ফল নয়

তিনটি শিক্ষা। প্রথমত, index ছাড়া join query-র চেয়ে প্রায় ৬ গুণ ধীর হয়েছে, কারণ ২০ বার পুরো OrderItem টেবিল পড়েছে, আর query পথে IN একবারেই পড়েছে। দ্বিতীয়ত, “এক query মানেই দ্রুত”, এই ধারণা ভুল। তৃতীয়ত, ডেটা বড় হলে পাল্লা বদলাতে পারে। আমাদের run-এ ৫,০০০ অর্ডার (index সহ, পণ্য-সহ, network ছাড়া) join-এ প্রায় ২৩৩ ms, query-তে প্রায় ৬৯ ms লেগেছে। Docs-ও বলে, join বেশিরভাগ ক্ষেত্রে ভালো, তবে profile করে দেখুন।

এবার ছোট টেবিলে নিজে দেখুন। নিচের কোডে তিনটি পথের SQL একসাথে আছে, আর শেষ সারিতে কোন পথে কতটি SQL লাগে তার হিসাব।

-- ক) N+1: আগে তালিকা
SELECT id, customer_id FROM orders ORDER BY id DESC;
-- তারপর প্রতিটি অর্ডারের জন্য একটি করে SQL
SELECT name FROM customers WHERE id = 1;
SELECT name FROM customers WHERE id = 2;
SELECT name FROM customers WHERE id = 1;

-- খ) query strategy-র মতো: id জমিয়ে একটি IN
SELECT id, name FROM customers WHERE id IN (1, 2);

-- গ) join: এক SQL-এই সব
SELECT o.id, c.name, COUNT(i.id) AS item_rows
FROM orders o
JOIN customers c ON c.id = o.customer_id
LEFT JOIN items i ON i.order_id = o.id
GROUP BY o.id, c.name
ORDER BY o.id DESC;

-- প্রতিটি পথে কতটি SQL?
SELECT 1 + COUNT(*) AS n_plus_one, 2 AS with_in, 1 AS with_join FROM orders;

৪ · অনেক ছোট query আর network-এর হিসাব

এতক্ষণ অ্যাপ আর ডেটাবেস একই কম্পিউটারে ছিল। বাস্তবে তারা আলাদা মেশিনে থাকে। তখন প্রতিটি query-র সাথে একটি round trip যোগ হয়, যার সময়কে বলে RTT. মোটামুটি সূত্র:

সূত্রটি সত্যি কি না মাপা হলো। Prisma আর PostgreSQL-এর মাঝে নিজের লেখা ছোট একটি TCP proxy বসানো হলো, যা প্রতি দিকে নির্দিষ্ট সময় ধরে রাখে। Index সহ ডেটা, ২০টি অর্ডার।

সত্যিকারের run · একটি local কম্পিউটারে · delay proxy দিয়ে RTT তৈরি করা, আসল network নয় · ৭ বার চালিয়ে মধ্যমা

হিসাব মেলান। RTT ৪০ ms-এ লুপ: ৪১ × ৪০ = ১,৬৪০ ms, সাথে ডেটাবেসের কাজ প্রায় ২১ ms, মোট ≈ ১,৬৬১ ms. মাপা ১,৬৭৩.৪ ms. query: ২ × ৪০ = ৮০, মাপা ৮২.৩. join: ১ × ৪০ = ৪০, মাপা ৪১.৭. সূত্র বেশ মিলছে।

এখন Promise.all সারিটি দেখুন। লুপের কলগুলো একসাথে পাঠালে SQL ৪১ থেকে ২২ হলো। কারণ Prisma-র docs বলে, একই tick-এর findUnique() কলগুলো নিজে থেকে batch হয়। সত্যিই log-এ ২০টি ক্রেতার জন্য একটি IN এসেছে। কিন্তু findMany()-এ এই সুবিধা নেই, তাই ২০টি থেকেই গেল। আর সময় ২ round trip নয়, ৪ round trip (১৬৫ ms). কেন? pg driver-এর connection pool-এ ডিফল্টে ১০টি সংযোগ, তাই ২১টি SQL তিন দফায় গেছে: ১ + ৩ = ৪. আমরা max: 30 দিয়ে আবার মাপলাম, সময় ১৬৪.৫ থেকে ৮৪.৩ ms হলো, হিসাব মিলে গেল।

Capacity-র হিসাব — একটি পূর্ণ numerical

একটি request-এর SQL-গুলো পরপর চলে, তাই সেই সময়জুড়ে সে প্রায় সবসময় একটি সংযোগ ধরে রাখে। ধরুন pool-এ ১০টি সংযোগ, RTT ৪০ ms, আর সবকিছু শুধু ডেটাবেস সংযোগে আটকে আছে। সংযোগ-সেকেন্ডের সরল হিসাবে প্রতি সেকেন্ডে সর্বোচ্চ request = সংযোগ ÷ প্রতি request-এর সময়।

একই server, একই ডেটাবেস, প্রায় ৪০ গুণ ধারণক্ষমতা। ক্যাম্পেইনের দিনে ৩০ জন একসাথে admin পাতা খুললেই লুপের পথে সারি জমবে। এটি হিসাবের অনুমান, মাপা ফল নয়। তবু N+1 কেন শুধু একজনের ধীরগতি নয়, পুরো অ্যাপের ধারণক্ষমতার প্রশ্ন, তা এখান থেকেই বোঝা যায়।

নিচের শেখানোর মডেলটি আসল ORM নয়, আর সময়ও আসল ঘড়ির নয়। RTT আর N বদলে নিজে সূত্রটি পরীক্ষা করুন।

// শেখানোর মডেল: নকল ORM, হিসাবের ঘড়ি। কোনো ডেটাবেস নেই।
const RTT = 10;     // ms, ধরে নেওয়া মান
const WORK = 0.3;   // প্রতি SQL-এ ডেটাবেসের কাজ, ms, ধরে নেওয়া মান

function fakeDb() {
  const db = { queries: 0, trips: 0, clock: 0 };
  // একসাথে পাঠানো SQL-গুলো এক round trip-এ যায়
  db.send = (...sql) => {
    db.queries += sql.length; db.trips += 1;
    db.clock += RTT + WORK * sql.length;
  };
  return db;
}
function loop(db, n) {
  db.send("orders");
  for (let i = 0; i < n; i++) {
    db.send("customer");
    db.send("items");
  }
}
const withIn = (db) => { db.send("orders"); db.send("customers IN", "items IN"); };
const withJoin = (db) => db.send("orders LATERAL JOIN");

function report(name, run) {
  const db = fakeDb();
  run(db);
  console.log(name.padEnd(12), String(db.queries).padStart(4), "queries",
    String(db.trips).padStart(4), "trips", db.clock.toFixed(1).padStart(8), "ms");
}
for (const n of [5, 20, 100]) {
  console.log("N =", n);
  report("loop", (db) => loop(db, n));
  report("IN", withIn);
  report("join", withJoin);
}

৫ · প্রতি request-এ query গোনা, আর budget test

N+1 ছোট ডেটায় চুপ থাকে, production-এ জেগে ওঠে। তাই চোখের ভরসায় না থেকে প্রতিটি request কতটি SQL চালাল, তা মাপুন। পর্ব ৩১-এ (Log আর config) আমরা AsyncLocalStorage দিয়ে request id পৌঁছে দিয়েছি। এখানে একই বাক্সে একটি counter রাখব।

import { AsyncLocalStorage } from 'node:async_hooks';
import { prisma } from './db.ts';

type Stats = { queries: number; dbMs: number };
export const stats = new AsyncLocalStorage<Stats>();

prisma.$on('query', (e) => {
  const s = stats.getStore();
  if (!s) return;              // request-এর বাইরের query
  s.queries += 1;
  s.dbMs += e.duration;
});

export async function countQueries<T>(fn: () => Promise<T>) {
  const s = { queries: 0, dbMs: 0 };
  const result = await stats.run(s, fn);
  return { result, queries: s.queries, dbMs: s.dbMs };
}

Express-এর একটি middleware প্রতিটি request-এর জন্য stats.run(s, next) ডাকে, আর res.on('finish')-এ একটি JSON লাইন লেখে। চারটি request একসাথে পাঠিয়ে দেখা হলো গণনা মিশে যায় কি না:

সত্যিকারের run · Express 5.3.0, Prisma 7.10.1, 127.0.0.1 · একবার · ~/bazarghar

{"url":"/api/orders?limit=20","status":200,"queries":1,"dbMs":23.4,"totalMs":24}
{"url":"/api/orders-loop?limit=20","status":200,"queries":41,"dbMs":18.7,"totalMs":26.3}
{"url":"/api/orders?limit=5","status":200,"queries":1,"dbMs":24.8,"totalMs":25.8}
{"url":"/api/orders-loop?limit=5","status":200,"queries":11,"dbMs":42.3,"totalMs":44.5}

গণনা ঠিক: ১ + ২ × ২০ = ৪১, ১ + ২ × ৫ = ১১, আর ভালো পথে ১. এই version-এ $on handler request-এর context পেয়েছে। তবু এটি আমাদের পরীক্ষায় পাওয়া আচরণ, docs-এ লেখা নিশ্চয়তা নয়, তাই version বদলালে আবার test চালান। dbMs-কে শুদ্ধ ডেটাবেস সময় ভাববেন না। Docs বলে duration হলো client query পাঠানো থেকে উত্তর পাওয়া পর্যন্ত সময়, তাই ব্যস্ত সময়ে এটি বাড়ে।

এবার সংখ্যাটিকে নিয়ম বানাই। Query budget মানে “এই endpoint ৫টির বেশি SQL চালাবে না”, আর সেটি test-এ লেখা। সময় নিয়ে test করলে কম্পিউটার ভেদে ফল নড়ে, কিন্তু query সংখ্যা স্থির থাকে। তাই এই test নির্ভরযোগ্য। দ্বিতীয় test আরও শক্তিশালী: N বাড়লেও query সংখ্যা একই থাকে কি না।

import { afterAll, describe, expect, it } from 'vitest';
import { prisma } from '../src/db.ts';
import { countQueries } from '../src/query-stats.ts';
import { listOrders, listOrdersLoop } from '../src/orders.ts';

const BUDGET = 5;
afterAll(() => prisma.$disconnect());

describe('অর্ডার তালিকার query budget', () => {
  it('২০টি অর্ডার: budget মেনে চলে', async () => {
    const { queries, result } = await countQueries(() => listOrders(20));
    expect(result).toHaveLength(20);
    expect(queries).toBeLessThanOrEqual(BUDGET);
  });
  it('অর্ডার বাড়লে query বাড়ে না', async () => {
    const a = await countQueries(() => listOrders(5));
    const b = await countQueries(() => listOrders(50));
    expect(b.queries).toBe(a.queries);
  });
  it('পুরোনো loop: budget ভাঙে', async () => {
    const { queries } = await countQueries(() => listOrdersLoop(20));
    expect(queries).toBeLessThanOrEqual(BUDGET);
  });
});

সত্যিকারের run · Vitest 5.0.5 · আসল PostgreSQL-এ · আউটপুট ছাঁটা · ~/bazarghar

$ npx vitest run
 RUN  v5.0.5 ~/bazarghar

 ❯ test/query-budget.test.ts (3 tests | 1 failed) 125ms
     × পুরোনো loop: budget ভাঙে 26ms

 FAIL  test/query-budget.test.ts > অর্ডার তালিকার query budget > পুরোনো loop: budget ভাঙে
AssertionError: expected 41 to be less than or equal to 5
 ❯ test/query-budget.test.ts:22:21

 Test Files  1 failed (1)
      Tests  1 failed | 2 passed (3)

এই ব্যর্থতাই আমরা চেয়েছি: test বলছে ৪১ > ৫. ডেটাবেস ছাড়াই একই ধারণা নিচে চালিয়ে দেখুন। এখানে query() একটি নকল driver, আর দুটি request একসাথে চলে।

const { AsyncLocalStorage } = require("node:async_hooks");
const assert = require("node:assert");
const store = new AsyncLocalStorage();
const wait = (ms) => new Promise((done) => setTimeout(done, ms));

// নকল driver: প্রতিটি SQL বর্তমান request-এর গণনায় যোগ হয়
async function query(sql) { await wait(1); store.getStore().queries += 1; }
async function listLoop(n) {
  await query("orders");
  for (let i = 0; i < n; i++) {
    await query("customer");
    await query("items");
  }
}
async function listInclude() {
  await query("orders");
  await Promise.all([query("customers IN"), query("items IN")]);
}
async function countQueries(fn) {
  const s = { queries: 0 };
  await store.run(s, fn);
  return s.queries;
}
async function main() {
  const [bad, good] = await Promise.all([
    countQueries(() => listLoop(20)), countQueries(() => listInclude()),
  ]);
  console.log("loop:", bad, " include:", good);
  assert.ok(good <= 5);
  try { assert.ok(bad <= 5, `budget 5, got ${bad}`); }
  catch (e) { console.log("FAILED:", e.message); }
}
main();

৬ · Pagination আর সম্পর্ক একসাথে

পর্ব ৩৪-এ (Pagination, filter আর sort) দেখেছেন, গভীর পাতায় cursor কেন ভালো। সম্পর্ক যোগ হলে দুটি নতুন কথা আসে।

প্রথমটি ভালো খবর। Prisma-তে take মূল টেবিলের সারি গোনে, সম্পর্কের নয়। হাতে লেখা সাধারণ JOIN … LIMIT 20-এ ঝামেলা হয়: এক অর্ডারে ৩টি পণ্য থাকলে join-এর ফলে তিনটি সারি হয়, তাই ২০টি সারি মানে মাত্র ৭টি অর্ডার। Prisma-র LATERAL আর IN, দুই পথেই আগে অর্ডার সীমিত হয়।

const page2 = await prisma.order.findMany({
  take: 3,
  skip: 1,                         // cursor সারিটি নিজে বাদ
  cursor: { id: lastId },
  orderBy: [{ createdAt: 'desc' }, { id: 'desc' }],
  include: { items: { select: { qty: true } } },
});

সত্যিকারের run · cursor 99998 · কলাম ছাঁটা

page 1  [ '100000:3', '99999:3', '99998:3' ]     page 2  [ '99997:3', '99996:3', '99995:3' ]

SELECT … FROM "Order" WHERE (("Order"."createdAt" = (SELECT "Order"."createdAt" FROM "Order" WHERE ("Order"."id") = ($1))
  AND "Order"."id" <= (SELECT "Order"."id" FROM "Order" WHERE ("Order"."id") = ($2)))
  OR ("Order"."createdAt" < (SELECT "Order"."createdAt" FROM "Order" WHERE ("Order"."id") = ($3))))
  ORDER BY "Order"."createdAt" DESC, "Order"."id" DESC LIMIT $4 OFFSET $5     [99998,99998,99998,"3","1"]
SELECT … FROM "OrderItem" WHERE "OrderItem"."orderId" IN ($1,$2,$3) OFFSET $4   [99997,99996,99995,"0"]

লক্ষ করুন, orderBy-এ শেষ কলাম id, তাই stable order বজায় আছে। আরেকটি খুঁটিনাটি: flag চালু থাকায় পাতা ১ এসেছে ১টি SQL-এ, কিন্তু cursor দেওয়া পাতা ২ আমাদের run-এ ২টি SQL-এ গেছে। তাই strategy ধরে না নিয়ে log দেখুন।

দ্বিতীয়টি ফাঁদ: সম্পর্কের ভেতরে take. “প্রতি ক্রেতার শেষ ৩টি অর্ডার” চাইলে:

prisma.customer.findMany({
  take: 20, orderBy: { id: 'asc' },
  relationLoadStrategy: 'query',   // এবং 'join'
  include: { orders: { take: 3, orderBy: { createdAt: 'desc' } } },
});

সত্যিকারের run · ৯ বার চালিয়ে মধ্যমা · SQL ছাঁটা · সাধারণ ফল নয়

query  queries=2  3.1 ms
  SELECT … FROM "Order" WHERE "Order"."customerId" IN ($1,…,$20) ORDER BY "Order"."createdAt" DESC OFFSET $21
join   queries=1  0.8 ms
  … LEFT JOIN LATERAL (… ORDER BY "t3"."createdAt" DESC LIMIT $1 …) AS "Customer_orders" ON true …

query পথের দ্বিতীয় SQL-এ কোনো LIMIT নেই! ২০ জন ক্রেতার প্রত্যেকের ১০০টি অর্ডার, মোট ২,০০০ সারি ডেটাবেস থেকে আসে, আর অ্যাপ প্রতিজনের ৩টি রেখে বাকিটা ফেলে দেয়। join পথে LIMIT প্রতি ক্রেতার ভেতরেই বসে। যে ক্রেতার ১ লাখ অর্ডার, তাঁর ক্ষেত্রে পার্থক্য বিশাল হবে।

৭ · গোনা আর যোগ: _count, groupBy আর raw SQL

“প্রতি ক্রেতার মোট অর্ডার” জানতে সব অর্ডার এনে .length দেখা মানে হিসাব জানতে পুরো খাতা বাড়ি নিয়ে যাওয়া। Aggregate হিসাবটি ডেটাবেসকেই করতে দিন।

// সম্পর্কের সংখ্যা: _count
prisma.customer.findMany({
  take: 20, orderBy: { id: 'asc' },
  select: { id: true, name: true, _count: { select: { orders: true } } },
});
// দলে ভাগ করে হিসাব: groupBy
prisma.order.groupBy({
  by: ['status'],
  _count: { _all: true },
  _sum: { total: true },
  orderBy: { _sum: { total: 'desc' } },
});

সত্যিকারের run · ৫ বার চালিয়ে মধ্যমা · আউটপুট ছাঁটা · সাধারণ ফল নয়

load all orders, count in JS   queries=1   10.5 ms   { id: 1, n: 100 }
_count                         queries=1    0.8 ms   { id: 1, name: 'Customer 1', _count: { orders: 100 } }

groupBy status                 queries=1   11.2 ms
  SELECT COUNT(*) AS "_count$_all", SUM("Order"."total") AS "_sum$total", "Order"."status"
  FROM "Order" WHERE 1=1 GROUP BY "Order"."status" ORDER BY SUM("Order"."total") DESC OFFSET $1
[ { _count: { _all: 30000 }, _sum: { total: 579437500 }, status: 'PAID' },
  { _count: { _all: 30000 }, _sum: { total: 554585000 }, status: 'DELIVERED' }, … ]

একই উত্তর, ১৩ গুণ দ্রুত, আর পথে অপ্রয়োজনীয় ডেটা নেই। GROUP BY-এর তত্ত্ব DBMS কোর্সে আছে।

কিন্তু একাধিক টেবিল জুড়ে রিপোর্টে ORM-এর API সীমিত। “জুন থেকে কোন ক্যাটাগরিতে কত আয়” চার টেবিলের join চায়। Prisma-র groupBy সম্পর্কের কলামে দল বাঁধতে পারে না, আর ORM জোর করে চালাতে গেলে কোড জটিল হয়। এখানে raw SQL সৎ পথ:

const from = new Date('2026-06-01T00:00:00Z');
const rows = await prisma.$queryRaw`
  SELECT c.name, COUNT(DISTINCT o.id) AS orders, SUM(i.qty * i.price) AS revenue
  FROM "OrderItem" i
  JOIN "Order" o    ON o.id = i."orderId"
  JOIN "Product" p  ON p.id = i."productId"
  JOIN "Category" c ON c.id = p."categoryId"
  WHERE o."createdAt" >= ${from} AND o.status <> 'CANCELLED'
  GROUP BY c.name ORDER BY revenue DESC LIMIT 3`;

সত্যিকারের run · ৩ বার চালিয়ে মধ্যমা · query=1 · 160.7 ms

[ { name: 'Category 9',  orders: 8477n, revenue: 85585728n },
  { name: 'Category 13', orders: 8477n, revenue: 85568072n },
  { name: 'Category 1',  orders: 8477n, revenue: 85533400n } ]

res.json(rows) → TypeError: Do not know how to serialize a BigInt

দুটি কথা মনে রাখুন। ${from} কোনো string জোড়া নয়। $queryRaw একটি tagged template, তাই মানটি parameter হয়ে যায়, আর SQL injection আটকায়। $queryRawUnsafe-এ string জুড়লে এই সুরক্ষা থাকে না। তত্ত্ব আছে Injection প্রতিরোধ পর্বে। আর দ্বিতীয়টি: PostgreSQL-এ COUNT আর বড় SUM-এর ফল BigInt হয়ে আসে, যা res.json() সরাসরি লিখতে পারে না। পাঠানোর আগে Number() বা string-এ বদলান, অথবা SQL-এ ::int cast করুন, তবে সংখ্যা সীমার মধ্যে আছে তা নিশ্চিত হয়ে।

৮ · ধীর query ধরা, EXPLAIN ANALYZE আর সঠিক index

প্রথম migration-এর SQL দেখলে একটি জিনিস চোখে পড়ে: foreign key আছে, কিন্তু তার index নেই। Prisma লিখেছিল শুধু এটুকু:

সত্যিকারের run · prisma/migrations/…_init/migration.sql থেকে · ছাঁটা

CREATE UNIQUE INDEX "Category_name_key" ON "Category"("name");
ALTER TABLE "OrderItem" ADD CONSTRAINT "OrderItem_orderId_fkey" FOREIGN KEY ("orderId") REFERENCES "Order"("id") …;

PostgreSQL foreign key-র কলামে নিজে থেকে index বানায় না, তার docs-ই এ কথা বলে। MySQL (InnoDB) বানায়। তাই PostgreSQL-এ এটি আপনার দায়িত্ব। এই ফাঁকই ১ নম্বর অংশের ৭৫৯ ms-এর বড় কারণ। ধরার পথ দুটি।

ডেটাবেসের দিক থেকে: Slow query log. PostgreSQL-এ log_min_duration_statement সীমার বেশি সময় নেওয়া প্রতিটি query log-এ লেখে। আমাদের run-এ সীমা ছিল ২০ ms. অ্যাপের দিক থেকে: ৫ নম্বর অংশের $on('query')-এ e.duration > 100 হলে একটি warning লেখা। একই আকৃতির query কতবার চলছে আর মোট কত সময় নিচ্ছে, তা দেখতে Performance tuning পর্বের pg_stat_statements দেখুন।

LOG:  duration: 27.901 ms  execute <unnamed>: SELECT "t0"."id", …
  FROM "public"."OrderItem" AS "t0" WHERE "t0"."orderId" = $1
DETAIL:  Parameters: $1 = '99995'
LOG:  duration: 28.551 ms  execute <unnamed>: SELECT "t0"."id", …
DETAIL:  Parameters: $1 = '99994'

Gather (actual time=17.291..25.988 rows=3.00 loops=1)
  Workers Launched: 2
  Buffers: shared hit=3822
  ->  Parallel Seq Scan on "OrderItem" (rows=1.00 loops=3)
        Filter: ("orderId" = 99999)
        Rows Removed by Filter: 99999
Execution Time: 26.008 ms

model OrderItem {
  …
  orderId   Int
  order     Order @relation(fields: [orderId], references: [id])

  @@index([orderId])
}

$ npx prisma migrate dev --name fk_indexes
Applying migration `…_fk_indexes`

-- CreateIndex
CREATE INDEX "OrderItem_orderId_idx" ON "OrderItem"("orderId");

Index Scan using "OrderItem_orderId_idx" on "OrderItem"
  (actual time=0.016..0.017 rows=3.00 loops=1)
  Index Cond: ("orderId" = 99999)
  Buffers: shared hit=4
Execution Time: 0.033 ms

লুপ (N+1)      759.0 ms  →  21.7 ms
include query   32.7 ms  →   1.8 ms
include join   199.4 ms  →   2.1 ms
Slow log-এ আর এই query নেই।

কোন index “সঠিক”?

একই query-তে তিন রকম index আলাদা ফল দেয়। ক্রেতার পাতায় চাই: where: { customerId: 77 }, নতুন আগে, ১০টি। ওই ক্রেতার ১০০টি অর্ডার আছে।

সত্যিকারের run · PostgreSQL 18.6 · ১ লাখ অর্ডার · সব ডেটা মেমরিতে · একবার · সাধারণ ফল নয়

দ্বিতীয় index সারি খুঁজে দেয়, কিন্তু সাজায় না। তৃতীয়টি (composite index) আগে ক্রেতা, তারপর সময় অনুযায়ী সাজানো, তাই ডেটাবেস প্রথম ১০টি পড়েই থামে। নিয়মটি: সমান-শর্তের কলাম আগে, তারপর sort-এর কলাম। নকশার পুরো আলোচনা Index design পর্বে। নিচে SQLite-এ নিজে চালিয়ে দেখুন।

-- ১) কোনো index নেই
EXPLAIN QUERY PLAN
SELECT id, total FROM orders
WHERE customer_id = 77 ORDER BY created_at DESC LIMIT 10;

-- ২) শুধু customer_id
CREATE INDEX o_cust ON orders(customer_id);
EXPLAIN QUERY PLAN
SELECT id, total FROM orders
WHERE customer_id = 77 ORDER BY created_at DESC LIMIT 10;

-- ৩) সমান-শর্ত আগে, sort পরে
DROP INDEX o_cust;
CREATE INDEX o_cust_new ON orders(customer_id, created_at DESC);
EXPLAIN QUERY PLAN
SELECT id, total FROM orders
WHERE customer_id = 77 ORDER BY created_at DESC LIMIT 10;

Index বিনামূল্যে নয়। আমাদের ৩০ MB-র OrderItem টেবিলে orderId index প্রায় ৪.৮ MB, আর প্রতিটি INSERT-এ সেটিও হালনাগাদ হয়। বড় চালু টেবিলে সাধারণ CREATE INDEX লেখা আটকে রাখে। তখন CREATE INDEX CONCURRENTLY লাগে, যা transaction-এর ভেতরে চলে না। আমাদের run-এ prisma migrate dev --create-only দিয়ে ফাইলটি বানিয়ে, তাতে শুধু ওই একটি statement রেখে, পরে apply করলে সেটি সফলভাবে চলেছে। তাই ভালো অভ্যাস হলো আগে slow log আর plan দেখা, তারপর index বসানো, আন্দাজে প্রতিটি কলামে নয়।

৯ · ORM PR review-এর চেকলিস্ট

এতক্ষণের সব শিক্ষা এক জায়গায়। ডেটাবেস ছোঁয়া যেকোনো PR-এ, নিজের হোক বা সহকর্মীর, এই প্রশ্নগুলো করুন। সাধারণ review-এর নিয়ম আছে Code review পর্বে।

• লুপ, .map() বা Promise.all-এর ভেতরে কোনো prisma. কল নেই
• include-এর জায়গায় select দিলে চলে কি না দেখেছি; লম্বা কলাম আসছে না
• তালিকার প্রতিটি query-তে take-এর সীমা আছে, ক্রম অনন্য (id শেষে)
• সম্পর্কের ভেতরের take কোন strategy-তে কী SQL বানাচ্ছে, log দেখেছি
• নতুন where আর orderBy-এর জন্য index আছে; PostgreSQL-এ foreign key-তেও
• .length বা JS-এর reduce-এর বদলে _count, aggregate, groupBy চলে কি না দেখেছি
• Raw SQL-এ শুধু $queryRaw, মান parameter হয়ে যাচ্ছে; BigInt সামলানো হয়েছে
• নতুন endpoint-এ query budget test আছে, N বাড়িয়েও পরীক্ষা করা
• বড় seed ডেটায় চালিয়েছি, ৫ সারির dev ডেটায় নয়

সব লুপই কি অপরাধ?

না। চেকলিস্ট চিন্তার জন্য, অন্ধ নিয়মের জন্য নয়। প্রতিদিন রাতে চলা একটি background job যদি ৫০০টি অর্ডার একটি করে সারায়, আর প্রতিটির পর email পাঠায়, সেখানে লুপ স্বাভাবিক। কেউ অপেক্ষায় নেই, আর একসাথে সব করলে একটি ব্যর্থতায় পুরো কাজ আটকে যেতে পারে। আবার যে সম্পর্ক সবসময় দু-তিনটি সারির, আর পাতাটি দিনে কয়েকবার খোলে, সেখানে দু-একটি বাড়তি query সরল কোডের দাম হিসেবে মেনে নেওয়া যায়। প্রশ্নটি হলো: N কে ঠিক করে, আর N কত বড় হতে পারে? N যদি ব্যবহারকারী বা ডেটার সাথে বাড়ে, তাহলে আজই সারান।

১০ · AI-এর যুগে: ORM কোড যাচাই

AI যে কোড লেখে তা প্রায়ই ছোট ডেটায় নিখুঁত চলে। N+1 ঠিক সেখানেই লুকায়। তাই AI-এর উত্তর না মেপে মেনে নেবেন না।

AI-এর ORM কোড হাতে পেলে

• Query log চালিয়ে আসল SQL নিজের চোখে দেখেছি
• আগে আর পরের query সংখ্যা ও সময় লিখে রেখেছি
• প্রতিটি option আমার version-এর docs-এ পেয়েছি, আর diff লাইন ধরে পড়েছি
• select-এ পাসওয়ার্ড বা অন্য গোপন কলাম ক্লায়েন্টে যাচ্ছে না; অন্যের অর্ডার দেখার অনুমতি যাচাই বাদ পড়েনি
• Error লুকানোর ফাঁকা catch নেই; budget test পাস করেছে