.NET Data Community Standup: 8 Real-World Query Anti‑Patterns (and How to Fix Them)

TL;DR

• 1

  N+1 queries are catastrophic in production — Woody and Shay Rojansky call this one of the worst anti-patterns because a harmless-looking foreach plus lazy loading can turn 1 query into hundreds once real latency and real data sizes hit.

• 2

  Include helps, but too much Include causes cartesian explosions — loading multiple one-to-many collections in one query can multiply rows dramatically, so AsSplitQuery() is often the fix, though it introduces consistency tradeoffs between separate queries.

• 3

  EF Core now protects you from the old client-side evaluation footgun — before EF Core 3, untranslatable logic in Where could silently pull entire tables into memory; now EF usually fails the query instead, except for safe projection in the final Select.

• 4

  Projection is the simplest way to stop overfetching — if a table has large columns like JSON or nvarchar(max), selecting whole entities effectively does a SELECT *, so projecting only needed fields into anonymous types or DTOs cuts payload size fast.

• 5

  Offset pagination (Skip/Take) works but keyset pagination is better — Shay argues that Skip gets slower as offsets grow and can duplicate or miss records during concurrent updates, while WHERE Id > lastSeenId is both faster and more correct.

• 6

  The real performance battle is often in the database, not C# — the group repeatedly stresses that missing indexes, poor query plans, and extra roundtrips matter far more than tiny runtime or allocation wins, so serious teams should inspect SQL and execution plans.