Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/optimizing-ef-core-queries
Optimize Entity Framework Core queries by fixing N+1 problems, choosing correct tracking modes, using compiled queries, and avoiding common performance traps.
Passed 21 of 22 test cases with the skill, and 21 of 22 without it.
1 fixed20 passed either way0 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
An EF Core application is experiencing unexplained slow response times in a critical endpoint, but the developer has not yet inspected the actual database traffic. What is the first diagnostic step to take in EF Core to inspect the query count and generated SQL statements?
| Checked | Without skill | With skill |
|---|---|---|
| recommends enabling EF Core logging via LogTo or Microsoft.EntityFrameworkCore.Database.Command | Passed | Passed |
| recommends tagging queries with TagWith to identify them in database logs | Missed | Passed |
The instructions your model reads when the skill loads.
Diagnose and fix slow Entity Framework Core (EF Core) queries. Start from the generated SQL/logs, apply the smallest change that removes the bottleneck, and confirm the fix by re-reading the SQL and the query count. Prefer changes that reduce round-trips, duplicated rows, scans, or per-call translation cost over micro-optimizations. Apply one change at a time and re-measure.
Includes blow up or duplicate rowsSkip grows, or bulk updates load rows just to modify themDbContext or recommend AsNoTracking, Include, AsSplitQuery, or other EF Core APIs.You cannot optimize what you cannot see. Turn on command logging and read the SQL and query count before changing anything:
optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);
// or set "Microsoft.EntityFrameworkCore.Database.Command": "Information" in appsettings.json
Tag a query with .TagWith("...") to find it in the log. Count how many statements a slow operation runs, and how many rows each returns, before and after each change.
An index can only be used when the indexed column appears bare on one side of the comparison. Wrapping it in a function or arithmetic — CreatedAt.Year == y, CreatedAt.Date == d, ToLower(Name) == n, Price * 1.1 > x, or a leading-wildcard LIKE '%foo' — forces a per-row computation the index cannot satisfy, so the query scans the whole table even though the index exists. Adding another index changes nothing. Rewrite the predicate so the column stays bare, usually as a half-open range:
// Non-sargable: a function is computed for every row → full scan
db.Logs.Where(l => l.CreatedAt.Year == year);
// Sargable: bare column compared to constants → index seek
var start = new DateTime(year, 1, 1);
test cases passed, vs 21 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.