optimizing-ef-core-queries
Optimize and improve the performance of slow Entity Framework Core (EF Core) queries: make them generate less SQL, make fewer database round-trips, and return results faster. Use whenever an EF Core or DbContext query or data-access path is slow or should be made faster — whether or not EF Core owns the database schema. For EF Core, not Dapper or raw ADO.NET.
Security Assessment
About optimizing-ef-core-queries
Optimizing EF Core Queries is a Microsoft dotnet/skills reference that diagnoses and fixes slow Entity Framework Core queries so they generate less SQL, make fewer database round-trips, and return results faster. It solves a common performance blind spot: developers optimize LINQ they cannot see translated, and add indexes that do nothing because the real problem is N+1 loading, Cartesian explosions from multiple Includes, non-sargable predicates, or per-call translation cost. Its method is measurement-first: capture the generated SQL and query count, apply the smallest change that removes the bottleneck, then re-read the SQL to confirm, one change at a time.
The skill walks through targeted fixes. It teaches keeping predicates sargable so an indexed column stays bare (rewriting year/date/lowercase/arithmetic and leading-wildcard comparisons into half-open ranges, normalized columns, or full-text search), compiling hot repeated query shapes with EF.CompileQuery, removing N+1 by projecting aggregates or eager-loading with Include instead of lazy loading, splitting multiple collection Includes with AsSplitQuery plus a stable OrderBy, and paginating with keyset (seek) pagination rather than deep Skip/Take. Each fix includes a concrete C# before/after and a verification step tied to query count, rows per statement, or duration. It also scopes itself precisely: it is for EF Core, not Dapper or raw ADO.NET, and says so in its when-not-to-use guidance.
It is aimed at .NET developers troubleshooting slow data-access paths who want disciplined, evidence-backed query tuning. It is read-and-advise reference content with no scripts or system access.
FAQ
What is the first thing it tells me to do?
Capture the generated SQL and query count before changing anything, by enabling command logging (LogTo or the Database.Command log level) and tagging the query with TagWith. You cannot optimize what you cannot see.
Does it apply to Dapper or raw ADO.NET?
No. It is for EF Core only. Its when-not-to-use guidance says to answer SQL/indexing/query-plan questions directly for Dapper or ADO.NET and not to introduce a DbContext or EF Core APIs like AsNoTracking or Include.
What problems does it target?
N+1 and lazy loading, Cartesian explosions from multiple collection Includes, non-sargable predicates that force full scans despite an index, deep-page Skip/Take cost, and per-call LINQ translation on hot query paths.
Why does adding an index sometimes not help?
Because the predicate is not sargable: wrapping the indexed column in a function or arithmetic forces a per-row computation the index cannot satisfy. The fix is to keep the column bare, usually via a half-open range, before considering a new index.
How does it verify a fix worked?
Each fix has a concrete verification: a seek instead of a scan with lower duration, a fixed small query count regardless of row count, fewer rows per statement, or lower mean time on a hot loop with identical results.
Install optimizing-ef-core-queries
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
dotnet/skills