Checklist
EF Core N+1 Audit Checklist
A 22-point audit to find, prove and fix N+1 queries before your customers do.
Who it’s for
For .NET teams whose EF Core endpoints are fine in development and slow in production, and who want a repeatable way to check a codebase rather than guess.
What’s inside
- How to make EF Core show its SQL, and what a query storm looks like in telemetry
- A read-path review: projection, Include, split queries and no-tracking
- The code patterns that hide lazy loading from a casual review
- Guard rails that stop N+1 coming back: query-count budgets and tests
Free preview
The full checklist has 22 checks. Here is the first section.
A. Detect it
EF Core command logging is on in development (LogTo, or the Microsoft.EntityFrameworkCore.Database.Command log category). Sensitive data logging stays off outside development.
You cannot judge what you cannot see. Repeated identical SELECTs with different parameters are the signature.
Your telemetry records database query count per request or operation.
Query count is the metric that exposes N+1. Latency alone hides it until it hurts.
A dashboard ranks endpoints by queries per request.
It turns a vague 'the app is slow' into a short, ordered list to work through.
An alert fires when an endpoint's query count is far above its normal.
N+1s are often introduced by an innocent change to a model or a mapping.
Development and test data are large enough to show the problem, or you reproduce slow endpoints against production-sized data.
At ten rows, 11 queries and 1 query feel the same.
Questions
- Is it really free?
- Yes. No payment and no sales call. You give me an email address and the PDF is yours.
- What will you do with my email?
- Send you the occasional note about similar resources and new writing. Reply “stop” and I’ll remove you.
- Can I share it with my team?
- Please do. Print it, adapt it, put it in your wiki. A link back to the site is appreciated.