तपाइँ N+1 क्वेरीहरू कसरी ठीक गर्नुहुन्छ र Eloquent लाई अनुकूलित गर्नुहुन्छ?

Question

Accepted Answer

**N+1 क्वेरी समस्या** — जहाँ लुपमा सम्बन्धहरूमा पहुँच प्रत्येक रेकर्डको लागि अलग क्वेरी ट्रिगर गर्दछ — सबैभन्दा सामान्य Eloquent कार्यक्षमता समस्या हो। **Eager loading** `with()` को साथ प्राथमिक समाधान हो, अन्य अनुकूलनहरूको साथमा (स्तम्भ चयन, chunking, indexing)।

## N+1 समस्या र यसको समाधान

```php
// ❌ N+1: 1 query for posts + 1 query PER post to load its author
$posts = Post::all();                         // 1 query
foreach ($posts as $post) {
    echo $post->author->name;                  // +1 query EACH → 100 posts = 101 queries!
}

// ✅ eager load with with() → 2 queries total (posts + all authors)
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;                  // no extra queries — authors prefetched
}
```

**`with()`** सम्बन्धहरूलाई अग्रिम रूपमा eager-load गर्दछ (प्रत्येक सम्बन्धको लागि एक अतिरिक्त क्वेरी बनाम प्रत्येक रेकर्डको लागि एक), 101 क्वेरीहरूलाई 2 मा परिणत गर्दछ — नाटकीय सुधार। यो आवश्यक Eloquent अनुकूलन हो।

## Eager loading भिन्नताहरू

```php
Post::with(['author', 'comments'])->get();        // multiple relationships
Post::with('comments.user')->get();                // nested
Post::with(['comments' => fn($q) => $q->latest()])->get();   // constrained
User::withCount('posts')->get();                   // count without loading (post_count)
```

## N+1 स्वचालित रूपमा पकड गर्दै

```php
// in development, make lazy loading THROW so you catch N+1 problems early
Model::preventLazyLoading();    // in a service provider (dev)
// or use Laravel Debugbar / Telescope to see query counts per request
```

**Debugbar/Telescope** जस्ता उपकरणहरूले प्रति पृष्ठ क्वेरी गणना देखाउँछन् (N+1 लाई दृश्यमान रूपमा चिन्न सकिन्छ), र `preventLazyLoading()` ले दुर्घटनाक्रम lazy loads लाई विकासको समय त्रुटिमा परिणत गर्दछ।

## अन्य Eloquent अनुकूलनहरू

```php
User::select('id', 'name')->get();             // fetch only needed columns
User::chunk(1000, fn($users) => ...);           // process huge sets in batches (memory)
User::cursor();                                  // lazy iteration — constant memory
// + add database INDEXES on filtered/joined columns (the biggest DB-level win)
// + use the query builder / database aggregation instead of PHP loops over collections
```

## यो किन महत्त्वपूर्ण छ

N+1 क्वेरीहरू ठीक गर्ने र Eloquent लाई अनुकूलित गर्ने काम Laravel अनुप्रयोगहरूको लागि महत्वपूर्ण कार्यक्षमता ज्ञान हो — **N+1 क्वेरी समस्या Laravel मा सबैभन्दा सामान्य र प्रभावशाली कार्यक्षमता समस्या हो**, र यसलाई कसरी रोक्ने भन्ने कुरा बुझ्ना आवश्यक छ।

यो समस्या विश्वासघाती छ किनभने Eloquent को सुविधाजनक सम्बन्ध पहुँच (`$post->author`) चुप चाप हरेक पल डाटाबेस क्वेरी ट्रिगर गर्दछ, त्यसैले कोड जो थोडै डाटामा राम्रोसँग काम गर्दछ डाटा बृद्धि हुँदै भयानक रूपमा घट्दछ (100 रेकर्ड 101 क्वेरी बन्ने), प्राय: उत्पादनमा लोडको अन्तर्गत मात्र पत्ता लगाइन्छ। **`with()` को साथ Eager loading** आवश्यक समाधान हो — सम्बन्धहरूलाई अग्रिम रूपमा दुई तीन क्वेरीमा लोड गर्ने बनाम प्रत्येक रेकर्डको लागि एक — र यसको भिन्नताहरू बुझ्ने (बहु, nested, constrained eager loads, `withCount`) सामान्य आवश्यकताहरू कभर गर्दछ।

समान रूपमा मूल्यवान **N+1 समस्याहरू पकड गर्ने** ज्ञान हो (Debugbar/Telescope क्वेरी गणना देख्न, विकासमा दुर्घटनाक्रम lazy loads लाई त्रुटिमा परिणत गर्न `preventLazyLoading()` गर्ने), त्यसैले तपाइँ उत्पादनमा अगाडि पनि पहिले तिनीहरूलाई खोज्नुहुन्छ।

N+1 को परे, अन्य अनुकूलनहरू — आवश्यक स्तम्भहरू मात्र चयन गर्ने, **chunking/cursors** ठूला डाटासेट प्रक्रिया गर्न स्मृति समाप्त नगरी, PHP-पक्ष संग्रह प्रक्रियाकरण भन्दा डाटाबेस एकीकरण, र महत्त्वपूर्ण रूपमा **अनुक्रमणिका** फिल्टर गरिएको/joined स्तम्भहरू (अक्सर सबैभन्दा ठूलो डाटाबेस-स्तरको जीत) — toolkitलाई पूरा गर्दछ।

यी बुझ्ने — विशेष गरी N+1 लाई बुझ्ने र eager loading को साथ ठीक गर्ने — महत्त्वपूर्ण सिनियर-स्तरको ज्ञान हो जसले विकासकर्ताहरूलाई अलग गर्दछ जसले performant Laravel अनुप्रयोगहरू लेख्छन् जसको अनुप्रयोगहरू डाटा बृद्धि हुँदै रेंगिएर जान्छ, यसलाई अनुप्रयोगहरू बनाउनको लागि बारम्बार-सान्दर्भिक, उच्च-मूल्य विषय बनाइदिन्छ जो स्केल गर्दछ।