⚠️ خطایی که کوئریهای EF Core شما را ۱۰۰ برابر کندتر میکند!
یک فراخوانی ساده متد تعیین میکند که آیا شرط Where شما به یک دستور SQL WHERE در دیتابیس تبدیل میشود یا کل جدول را ابتدا وارد حافظه (RAM) میکند! متأسفانه بسیاری از توسعهدهندگان به این تفاوت دقت نمیکنند.
هر دو متد تسلسلی برمیگردانند که میتوانید روی آن کوئری بزنید، اما تنها یکی از آنها همچنان با دیتابیس صحبت میکند.
🔹 متد AsEnumerable
میپرسد: *"باقی عملیات در حافظه انجام شود؟"*
▫️ کوئری را به LINQ-to-Objects سوئیچ میکند.
▫️ تمام فیلترهای بعد از این نقطه به صورت Client-side و پس از دانلود کامل دادهها از دیتابیس، در برنامه شما اجرا میشوند.
🔹 متد AsQueryable
میپرسد: *"اجازه بده Database Provider آن را ترجمه کند؟"*
▫️ ساختار کوئری را به صورت Expression Tree نگهمیدارد.
▫️ تمام فیلترهای بعد از این نقطه به SQL ترجمه شده و به صورت Server-side در دیتابیس اجرا میشوند.
❌ اشتباهی که در پروژهها رخ میدهد:
اگر متد AsEnumerable را تنها یک خط زودتر صدا بزنید و بعد فیلتر اعمال کنید، تمام دادههای جدول را روی شبکه منتقل کردهاید پیش از آنکه شرط WHERE اجرا شود!
کد بدون خطا کامپایل میشود و نتیجه درست هم میدهد، اما فرآیند اجرا میتواند ۱۰۰ برابر سنگینتر و کندتر شود.
👨💻 نمونه کد مقایسهای:
// ❌ BAD: Loads all users into memory first, then filters in C#!
var slowUsers = dbContext.Users
.AsEnumerable() // Switched to LINQ-to-Objects (Client-side)
.Where(u => u.IsActive && u.Age > 18)
.ToList();
// ✅ GOOD: Translates filter to SQL WHERE clause in Database!
var fastUsers = dbContext.Users
.AsQueryable() // Keeps Expression Tree (Server-side)
.Where(u => u.IsActive && u.Age > 18)
.ToList();
💡 نکته کلیدی:
اگر کوئری شما با وجود داشتن Index مناسب، به طرز مرموزی کند اجرا میشود، حتماً بررسی کنید که آیا قبل از اعمال فیلترها، کوئری به LINQ-to-Objects سوئیچ کرده است یا خیر.
3 · 235 · Message⚠️ خطایی که کوئریهای EF Core شما را ۱۰۰ برابر کندتر میکند!
27 September 2026Nearby in the feed
Athis message
D