❌ Common EF Core LINQ Mistakes to Avoid for Better Performance 🚫

Writing LINQ with Entity Framework Core is powerful — but small mistakes can lead to serious performance hits, data issues, and runtime exceptions. Here's a list of real-world mistakes developers commonly make (and how to avoid them) when working with EF Core LINQ.

1️⃣ Calling .ToList() Too Early 🐌

Mistake: Fetching data into memory before filtering.
Why it's bad: Increases memory usage and queries unnecessary data from the database.

// ❌ Inefficient
var users = db.Users.ToList().Where(u => u.IsActive);

// ✅ Efficient
var users = db.Users.Where(u => u.IsActive).ToList();

2️⃣ Forgetting .AsNoTracking() on Read-Only Queries 🧾

Mistake: Using default tracking for queries that don’t need updates.
Why it's bad: Adds unnecessary memory overhead, which impacts performance when you're only reading data.

// ✅ Recommended for read-only queries
var users = db.Users.AsNoTracking().ToList();

🧠 Tip: Use .AsNoTracking() for queries where you don't plan to update the entities. It keeps your DbContext lightweight and improves read performance.

3️⃣ Using Include() Without Needing the Related Data 📦

Mistake: Eager loading navigation properties even when not used.
Why it's bad: Bloats queries, increases data transfer size, and slows down performance.

// ❌ Don’t use Include if you don't need related data
var orders = db.Orders.Include(o => o.Customer).ToList();

🧠 Tip: Only use .Include() when you're going to access the related data. Otherwise, stick to lazy loading or just avoid loading unused relationships.

4️⃣ Querying Navigation Collections in Loops (N+1 Problem) 🔁

Mistake: Running queries inside loops for related data.
Why it's bad: Sends multiple queries to the database — one per item in the loop — drastically slowing down your app (the classic N+1 problem).

// ❌ Triggers a query per user
foreach (var user in db.Users.ToList())
{
    var orders = db.Orders.Where(o => o.UserId == user.Id).ToList();
}

// ✅ Optimized with eager loading
var usersWithOrders = db.Users.Include(u => u.Orders).ToList();

5️⃣ Not Using Projections with .Select() 🎯

Mistake: Fetching full entities when only specific fields are needed.
Why it's bad: Loads unnecessary data into memory, increasing query time and memory usage — especially with large datasets.

// ❌ Loads all fields
var users = db.Users.Where(u => u.IsActive).ToList();

// ✅ Loads only what's needed
var userSummaries = db.Users
    .Where(u => u.IsActive)
    .Select(u => new { u.Name, u.Email })
    .ToList();

🧠 Tip: Use .Select() to project only the fields you need. It makes queries faster and keeps your application lean.

6️⃣ Using Count() Instead of Any() for Existence Checks 🔍

Mistake: Checking for the existence of records using .Count() > 0.
Why it's bad: .Count() scans all matching records, even after finding the first. .Any() short-circuits and stops once it finds a match — making it much faster.

// ❌ Slower
if (db.Users.Where(u => u.IsActive).Count() > 0)

// ✅ Faster
if (db.Users.Any(u => u.IsActive))

🧠 Tip: Use .Any() when you're checking if at least one record exists. It's optimized for performance and is the correct semantic approach.

7️⃣ Mixing IQueryable with IEnumerable Too Soon ⚠️

Mistake: Materializing data early and filtering in memory.
Why it's bad: You lose the benefits of SQL-side filtering, resulting in slower performance on large datasets.

// ❌ In-memory filtering
var data = db.Users.ToList().Where(u => u.IsActive);

// ✅ DB-side filtering
var data = db.Users.Where(u => u.IsActive).ToList();

8️⃣ Writing Logic EF Core Can’t Translate to SQL ❌

Mistake: Using methods in LINQ that EF Core can't convert to SQL.
Why it's bad: Causes runtime exceptions or forces client-side evaluation, which can crash your app or severely degrade performance.

// ❌ Won’t work if MyCustomMethod is not translatable
var users = db.Users.Where(u => MyCustomMethod(u.Name)).ToList();

9️⃣ Not Disposing DbContext Properly 💥

Mistake: Keeping DbContext alive for too long or forgetting to dispose of it.
Why it's bad: Can lead to memory leaks, connection pool exhaustion, and unstable application behavior.

// ✅ Always dispose properly
using(var context = new MyDbContext())
{
    var users = context.Users.ToList();
}

🔟 Not Reviewing Generated SQL ❓

Mistake: Assuming LINQ always generates optimized SQL.
Why it's bad: You might be executing inefficient joins, nested subqueries, or pulling unnecessary columns without realizing it.

// ✅ Use ToQueryString() to inspect generated SQL
var query = db.Users.Where(u => u.IsActive);
Console.WriteLine(query.ToQueryString());

✅ Final Thoughts

Entity Framework Core makes querying intuitive — but one wrong move can kill your performance or crash production. Avoiding these common EF Core LINQ mistakes will help you write faster, cleaner, and more maintainable code.

💡 Pro Tip: Always profile your SQL, avoid unnecessary data loads, and prefer server-side execution whenever possible!