optimizing-ef-core-queries

Fix N+1 queries in EF Core by eager loading related data with Include, using AsSplitQuery for multiple collections to avoid cartesian explosion, or projecting only needed columns with Select. Enable SQL logging first to confirm the N+1 pattern exists.

Use AsNoTracking for read-only queries where entities will not be updated, since change tracking adds significant overhead. Use AsNoTrackingWithIdentityResolution when queries return duplicate entities to avoid duplicated objects in memory.

A single Include query joins everything in one SQL statement, which risks cartesian explosion with multiple collections. AsSplitQuery issues separate SQL statements per collection, which is better for multiple Includes or large child collections.

No, this guidance is specific to Entity Framework Core. If you use Dapper or raw ADO.NET, or if the bottleneck is database-side like missing indexes or schema design, these EF Core techniques do not apply.

This happens when ToList is called before Where, causing the full table to load before filtering in memory. Always apply Where filters before materializing with ToList so filtering happens in SQL.

In EF Core 7 and later, use ExecuteUpdateAsync and ExecuteDeleteAsync to run bulk operations directly in SQL without loading entities into memory. This avoids the fetch-then-save pattern that causes unnecessary round trips.