آپ N+1 queries کو کیسے ٹھیک کرتے ہیں اور Eloquent کو optimize کیسے کرتے ہیں؟

Question

Accepted Answer

**N+1 query problem** — جہاں ایک loop میں relationships کو access کرنے سے ہر record کے لیے الگ query trigger ہوتی ہے — یہ سب سے عام Eloquent performance issue ہے۔ **Eager loading** کے ذریعے `with()` استعمال کرنا بنیادی حل ہے، ساتھ میں دوسری optimizations (columns کو select کرنا، chunking، indexing)۔

## N+1 problem اور اس کا حل

```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()`** relationships کو شروع سے eager-load کرتا ہے (ہر relationship کے لیے ایک اضافی query بجائے ہر record کے لیے)، 101 queries کو 2 میں تبدیل کرتا ہے — ایک نمایاں بہتری۔ یہ ضروری Eloquent optimization ہے۔

## Eager loading کی variations

```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** جیسے tools ہر page کے لیے query counts دکھاتے ہیں (N+1 کو بصری طور پر دیکھیں)، اور `preventLazyLoading()` غیر ارادی lazy loads کو development میں غلطیوں میں تبدیل کرتا ہے۔

## دیگر Eloquent optimizations

```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 queries کو ٹھیک کرنا اور Eloquent کو optimize کرنا Laravel applications کے لیے اہم performance knowledge ہے — **N+1 query problem Laravel میں واحد سب سے عام اور اہم performance issue ہے**، اور اسے روکنے کا طریقہ سمجھنا ضروری ہے۔

مسئلہ خطرناک ہے کیونکہ Eloquent کی سہل relationship access (`$post->author`) خاموشی سے ہر بار database query trigger کرتی ہے، اس لیے code جو کم data کے ساتھ ٹھیک کام کرتا ہے وہ catastrophically گراتا ہے جیسے جیسے data بڑھتا ہے (100 records 101 queries بن جاتے ہیں)، اکثر صرف production میں load کے تحت دریافت ہوتے ہیں۔ **`with()`** کے ساتھ eager loading بنیادی حل ہے — relationships کو شروع سے ایک جوڑے سوالات میں load کرنا بجائے ہر record کے لیے — اور اس کی variations جاننا (متعدد، nested، constrained eager loads، `withCount`) عام ضروریات کا احاطہ کرتا ہے۔

برابر قیمتی ہے جاننا کہ **N+1 problems کو کیسے پکڑیں** (Debugbar/Telescope query counts دیکھنے کے لیے، `preventLazyLoading()` تاکہ غیر ارادی lazy loads development میں غلطیاں بن جائیں)، تاکہ آپ انہیں production سے پہلے تلاش کریں۔

N+1 کے علاوہ، دوسری optimizations — صرف ضروری columns select کرنا، **chunking/cursors** بڑے datasets کو memory ختم کیے بغیر process کرنے کے لیے، database aggregation PHP-side collection processing کی بجائے، اور اہم طور پر **indexing** filtered/joined columns (اکثر سب سے بڑی database-level جیت) — toolkit کو مکمل کرتے ہیں۔

ان کو سمجھنا — خاص طور پر N+1 کو eager loading سے recognize اور fix کرنا — اہم senior-level knowledge ہے جو ان developers کو الگ کرتا ہے جو performant Laravel applications لکھتے ہیں ان سے جن کی apps data بڑھتے ہوئے crawl میں سست ہو جاتی ہیں، اس لیے یہ ایک بار بار relevant، زیادہ قیمت والا topic ہے applications بنانے کے لیے جو scale کرتے ہیں۔