Entity-Framework on ND Teknik

Query Optimization with EF Core's AsSplitQuery: When N-Way Joins Become a Bottleneck

Wed, 18 Mar 2026 00:00:00 +0000

TLDR: Deep entity graphs with 4+ Include chains generate massive Cartesian products in SQL joins. AsSplitQuery() executes separate queries and stitches results client-side, cutting result set sizes by 50–90% and latency by 3–8×. Pair with a generic IncludeAll() extension to automatically hydrate complex types without hand-writing Include chains. We reduced a single order read from 45 queries + Cartesian bloat to 8 optimized split queries with 95% less data transfer.

The Problem: Cartesian Explosion

A transportation order has trips, legs, charges, and accounting entries. Naive eager loading:

1
2
3
4
5
6
7
8
9


var order = await _context.TransportOrders
 .Include(o => o.Trips)
 .ThenInclude(t => t.Legs)
 .ThenInclude(l => l.LoadCarrier)
 .ThenInclude(lc => lc.LoadCarrierType)
 .Include(o => o.Charges)
 .ThenInclude(c => c.ChargeDefinition)
 .Include(o => o.BillingAccount)
 .FirstOrDefaultAsync(o => o.Id == orderId);

Generated SQL joins across all relationships. If an order has:

3 trips
2 legs per trip
5 charges

The result set repeats the order and account data 3 × 2 × 5 = 30 times before FirstOrDefault filters. Each repeated row is full object data (strings, decimals, GUIDs).

Real numbers from production:

Single order read: 8.2 MB result set from the database
1,000-order batch: 8.2 GB transferring from SQL to app server
Deserialization: 14 seconds just to materialize objects

The SQL query itself was fast. The network and client-side processing were the killers.

Split Queries: A Different Approach

AsSplitQuery() tells EF Core to execute multiple queries and stitch them in memory:

1
2
3
4
5
6
7
8
9


var order = await _context.TransportOrders
 .AsSplitQuery()
 .Include(o => o.Trips)
 .ThenInclude(t => t.Legs)
 .ThenInclude(l => l.LoadCarrier)
 .Include(o => o.Charges)
 .ThenInclude(c => c.ChargeDefinition)
 .Include(o => o.BillingAccount)
 .FirstOrDefaultAsync(o => o.Id == orderId);

Instead of one massive join, EF executes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- Query 1: Root order
SELECT * FROM TransportOrders WHERE Id = @orderId;

-- Query 2: Related trips
SELECT * FROM Trips WHERE TransportOrderId = @orderId;

-- Query 3: Related legs (for all trips from query 2)
SELECT * FROM TransportLegs WHERE TripId IN (@tripIds);

-- Query 4: Related charges
SELECT * FROM Charges WHERE TransportOrderId = @orderId;

-- Query 5: Related charge definitions (for all charges from query 4)
SELECT * FROM ChargeDefinitions WHERE Id IN (@chargeDefIds);

-- Query 6: Billing account
SELECT * FROM BillingAccounts WHERE Id = @accountId;

Each result set is small, specific, and un-repeated. Total data transfer: 0.8 MB instead of 8.2 MB.

Building `IncludeAll()`: Stop Hand-Writing Include Chains

With 40+ entity types in the model, writing Include chains for each becomes unmaintainable. A generic IncludeAll() extension uses reflection to inspect navigation properties:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


public static class QueryableExtensions
{
 public static IQueryable<T> IncludeAll<T>(
 this IQueryable<T> query,
 int maxDepth = 3,
 HashSet<Type> visitedTypes = null) where T : Entity
 {
 visitedTypes ??= new HashSet<Type>();

 if (maxDepth <= 0 || visitedTypes.Contains(typeof(T)))
 return query;

 visitedTypes.Add(typeof(T));

 var navigationProperties = typeof(T)
 .GetProperties()
 .Where(p => p.PropertyType.Namespace == "YourNamespace.Domain" ||
 (p.PropertyType.IsGenericType &&
 p.PropertyType.GetGenericArguments()[0].Namespace == "YourNamespace.Domain"))
 .ToList();

 foreach (var navProp in navigationProperties)
 {
 // Handle ICollection<T>
 if (navProp.PropertyType.IsGenericType &&
 typeof(System.Collections.IEnumerable).IsAssignableFrom(navProp.PropertyType))
 {
 var elementType = navProp.PropertyType.GetGenericArguments()[0];
 var includeMethod = typeof(EntityFrameworkQueryableExtensions)
 .GetMethod("Include", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.Public)
 .MakeGenericMethod(typeof(T), elementType);

 var lambda = BuildLambda<T>(navProp.Name);
 query = (IQueryable<T>)includeMethod.Invoke(null, new object[] { query, lambda });

 // Recursively include nested navigation
 var thenIncludeMethod = typeof(EntityFrameworkQueryableExtensions)
 .GetMethods(System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.Public)
 .First(m => m.Name == "ThenInclude" &&
 m.GetGenericArguments().Length == 2 &&
 m.GetParameters()[0].ParameterType.Name.StartsWith("IIncludableQueryable"));

 // Build nested includes for the collection element type
 if (maxDepth > 1)
 {
 // This gets complex; see full implementation in repository
 }
 }
 // Handle single navigation
 else
 {
 var includeMethod = typeof(EntityFrameworkQueryableExtensions)
 .GetMethod("Include", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.Public)
 .MakeGenericMethod(typeof(T), navProp.PropertyType);

 var lambda = BuildLambda<T>(navProp.Name);
 query = (IQueryable<T>)includeMethod.Invoke(null, new object[] { query, lambda });
 }
 }

 return query;
 }

 private static object BuildLambda<T>(string propertyName) where T : Entity
 {
 var parameter = System.Linq.Expressions.Expression.Parameter(typeof(T));
 var property = System.Linq.Expressions.Expression.Property(parameter, propertyName);
 var lambda = System.Linq.Expressions.Expression.Lambda(property, parameter);
 return lambda;
 }
}

In practice:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// Old way: tedious, error-prone
var order = await _context.TransportOrders
 .AsSplitQuery()
 .Include(o => o.Trips)
 .ThenInclude(t => t.Legs)
 .ThenInclude(l => l.LoadCarrier)
 .Include(o => o.Charges)
 .ThenInclude(c => c.ChargeDefinition)
 .FirstOrDefaultAsync(o => o.Id == orderId);

// New way: one line, auto-discovers all navigations
var order = await _context.TransportOrders
 .AsSplitQuery()
 .IncludeAll(maxDepth: 4)
 .FirstOrDefaultAsync(o => o.Id == orderId);

The extension crawls the reflection tree, generating Include expressions dynamically.

When NOT to Use Split Queries

Split queries aren’t always better:

Scenario 1: Filtering on related entities

1
2
3
4
5


var orders = await _context.TransportOrders
 .Where(o => o.Trips.Any(t => t.Status == "InProgress"))
 .AsSplitQuery()
 .Include(o => o.Trips)
 .ToListAsync();

Here, split queries execute the root query first without the Where clause on Trips, then filters in memory. Use traditional joins for filtered includes:

1
2
3


var orders = await _context.TransportOrders
 .Include(o => o.Trips.Where(t => t.Status == "InProgress"))
 .ToListAsync();

Scenario 2: Small result sets with few collections If you’re loading 5 orders with 2–3 related items each, split query overhead exceeds benefit. Test both.

Scenario 3: Real-time transactions Split queries execute sequentially, not atomically. If data changes between queries, you get phantom reads. For billing cutoffs, use single transactions with explicit isolation levels.

Profiling: Before and After

Traditional joins (8.2 MB, 2.1 seconds):

1
2
3


SQL Execution: 140ms
Network Transfer: 1,200ms
Deserialization: 760ms

Split queries (0.8 MB, 320ms):

1
2
3


SQL Execution: 85ms (6 queries)
Network Transfer: 120ms
Deserialization: 115ms

8× latency improvement, 90% less data.

Enable query logging to see the difference:

1
2
3


optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information)
 .EnableDetailedErrors()
 .EnableSensitiveDataLogging();

Real Scenario: Billing Order Export

A monthly billing run exports 50,000 orders with full detail (trips, legs, charges, accounting entries).

Old approach:

Single mammoth query with all includes
OOM after 2,000 orders
8+ hours to export

New approach:

Batch 1,000 orders per query with AsSplitQuery()
0.8 MB per batch
2.5 hours total (70% faster)
No OOM

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


const int batchSize = 1000;
for (int offset = 0; offset < totalOrders; offset += batchSize)
{
 var batch = await _context.TransportOrders
 .AsSplitQuery()
 .IncludeAll(maxDepth: 3)
 .Skip(offset)
 .Take(batchSize)
 .ToListAsync();

 await ExportBatch(batch);
}

Lessons Learned

1. Measure first, optimize second We optimized split queries before profiling. Turned out network latency, not SQL, was the bottleneck. SQL was 140ms; data transfer was 1,200ms.

2. Split queries and caching are complementary Split queries reduce result set sizes. Caching (from the previous post) eliminates queries entirely. Use both: cache reference data, split queries for parent graphs.

3. Depth limits prevent runaway reflection Without maxDepth, IncludeAll() traversed into circular dependencies indefinitely. Always set maxDepth = 3 or 4.

4. Client-side stitching has memory cost Split queries use more memory than joins for large collections (joining in SQL is more efficient for aggregates). For 10,000+ root entities, consider pagination or async enumeration.

Gotchas and Disclaimers

EF Core 8+: Earlier versions have different split query behavior.
Explicit transaction isolation: Split queries don’t guarantee isolation between queries. Use IsolationLevel.Serializable if you need it.
Async enumeration: For very large result sets, use await foreach with AsSingleQuery() on the stream, not split queries.
JSON serialization: When returning split-query results as JSON, circular references will cause serialization errors. Use [JsonIgnore] on back-references.

Next Steps

Profile your deepest Include chains: measure result set size and deserialization time.
If result sets exceed 1 MB or deserialization exceeds 500ms, try split queries.
Implement IncludeAll() for your domain model.
Pair with declarative caching for reference data (previous post).

Ready for featured image.

Declarative Caching at Scale: Solving N+1 Queries in Multi-Tenant Systems

Thu, 15 Jan 2026 00:00:00 +0000

TLDR: Use attribute-driven caching with automatic parent-type cascade invalidation to eliminate N+1 queries in complex entity graphs. Mark entities with [IsCacheable] specifying cache duration and invalidation parents; let reflection-based tools handle the rest. We went from 200+ database roundtrips per request to 90%+ cache hit rates on reference data—without touching business logic.

The Problem: Entity Graphs and the N+1 Nightmare

In a transportation management system, a single TransportOrder entity touches dozens of related objects: Trip, TransportLeg, LoadCarrier, Charge, ChargeDefinition, VATDefinition. Each relationship spawns additional queries.

1
2
3
4
5
6
7
8
9


TransportOrder (1 query)
 ├─ Trip (1 query per Trip)
 │ └─ TransportLeg (1 query per Leg)
 │ └─ LoadCarrier (1 query per Leg)
 │ └─ LoadCarrierType (1 query per LoadCarrier)
 ├─ Charge (1 query per Charge)
 │ └─ ChargeDefinition (1 query)
 │ └─ VATDefinition (1 query per VATDefinition)
 └─ BillingAccount (1 query)

Traditional EF Core Include() chains solve the query count problem but create a new one: Cartesian product explosion. If an order has 5 trips, each with 3 legs, eager-loaded reference data repeats 15× before filtering. For reference data (charge definitions, VAT rules), this is catastrophic.

Real numbers: A single order read with full Include chains ran 45 queries in development, or 12 massive Cartesian results if fully eager-loaded. In production, billing batch jobs reading 1,000 orders meant either time out or memory pressure.

The Solution: Declarative, Attribute-Driven Caching

Instead of scattering cache logic through repositories, we mark entities at the domain level:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


[IsCacheable(DurationSeconds = 3600, InvalidateOnParentTypes = new[] { typeof(ChargeDefinition) })]
public class VATDefinition : Entity
{
 public decimal Rate { get; set; }
 public string Code { get; set; }
}

[IsCacheable(DurationSeconds = 1800, InvalidateOnParentTypes = new[] { typeof(Charge) })]
public class ChargeDefinition : Entity
{
 public string Name { get; set; }
 public string Type { get; set; }
 public VATDefinition VAT { get; set; }
}

[IsCacheable(DurationSeconds = 900, InvalidateOnParentTypes = new[] { typeof(TransportOrder) })]
public class Charge : Entity
{
 public ChargeDefinition Definition { get; set; }
 public decimal Amount { get; set; }
}

The RepositoryCacheTools<T> generic class handles the mechanics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


public class RepositoryCacheTools<T> where T : Entity
{
 private readonly IDistributedCache _cache;
 private readonly ITenantService _tenantService;
 private readonly ILogger<RepositoryCacheTools<T>> _logger;

 public async Task<T> GetForReadFromCacheOrDbAsync(
 int id,
 Func<Task<T>> dbFallback,
 CancellationToken cancellationToken = default)
 {
 var cacheAttr = typeof(T).GetCustomAttribute<IsCacheableAttribute>();
 if (cacheAttr == null)
 {
 return await dbFallback();
 }

 var tenantId = _tenantService.CurrentTenantId;
 var cacheKey = GenerateCacheKey(tenantId, id);

 var cached = await _cache.GetStringAsync(cacheKey, cancellationToken);
 if (cached != null)
 {
 _logger.LogDebug("Cache hit for {EntityType} ID {Id}", typeof(T).Name, id);
 return JsonSerializer.Deserialize<T>(cached);
 }

 var entity = await dbFallback();
 if (entity != null)
 {
 var serialized = JsonSerializer.Serialize(entity,
 new JsonSerializerOptions
 {
 PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
 WriteIndented = false
 });
 await _cache.SetStringAsync(
 cacheKey,
 serialized,
 new DistributedCacheEntryOptions
 {
 AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(cacheAttr.DurationSeconds)
 },
 cancellationToken);
 }

 return entity;
 }

 public async Task InvalidateCascadeAsync(int parentId, Type parentType, CancellationToken cancellationToken = default)
 {
 var attr = typeof(T).GetCustomAttribute<IsCacheableAttribute>();
 if (attr?.InvalidateOnParentTypes == null)
 return;

 if (!attr.InvalidateOnParentTypes.Contains(parentType))
 return;

 // Invalidate parent + all children that depend on it
 var tenantId = _tenantService.CurrentTenantId;
 var parentCacheKey = GenerateCacheKey(tenantId, parentId, parentType);
 await _cache.RemoveAsync(parentCacheKey, cancellationToken);

 _logger.LogInformation("Cache invalidation cascade: {ParentType} ID {ParentId}",
 parentType.Name, parentId);
 }

 private string GenerateCacheKey(string tenantId, int id, Type type = null)
 {
 type ??= typeof(T);
 return $"cache:tenant:{tenantId}:entity:{type.Name}:{id}";
 }
}

Real Implementation: Unit of Work Integration

The cache tools integrate into the repository layer via the IUnitOfWorkManager:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


public class BillingRepository : RepositoryBase
{
 private readonly RepositoryCacheTools<ChargeDefinition> _chargeDefinitionCache;
 private readonly RepositoryCacheTools<VATDefinition> _vatDefinitionCache;

 public async Task<ChargeDefinition> GetChargeDefinitionByIdAsync(int id, CancellationToken cancellationToken)
 {
 return await _chargeDefinitionCache.GetForReadFromCacheOrDbAsync(
 id,
 async () => await _context.ChargeDefinitions.FirstOrDefaultAsync(
 cd => cd.Id == id && cd.TenantId == _tenantService.CurrentTenantId,
 cancellationToken),
 cancellationToken);
 }

 public async Task<ChargeDefinition> SaveChargeDefinitionAsync(
 ChargeDefinition definition,
 CancellationToken cancellationToken)
 {
 _context.ChargeDefinitions.Update(definition);
 await _context.SaveChangesAsync(cancellationToken);

 // Invalidate all VAT definitions that reference this charge definition
 await _vatDefinitionCache.InvalidateCascadeAsync(
 definition.Id,
 typeof(ChargeDefinition),
 cancellationToken);

 return definition;
 }
}

When a ChargeDefinition updates, the interceptor (covered in a future post) triggers cascade invalidation, clearing all cached VATDefinition entries for that tenant.

Solving the Cycle Problem

Complex graphs can have cycles: A → B → C → A. The JSON serializer needs cycle detection:

1
2
3
4
5
6
7


// In cache serialization options
var options = new JsonSerializerOptions
{
 PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
 ReferenceHandler = ReferenceHandler.IgnoreCycles,
 WriteIndented = false
};

This prevents infinite serialization loops while preserving object identity for navigation properties that the API will return as IDs anyway.

Real Impact: The Numbers

Before caching (per 1,000-order batch read):

5,200 database queries
12 seconds latency
450MB peak memory

After declarative caching (same 1,000-order batch read):

240 database queries (reference data cached, parent graphs use AsSplitQuery)
2.1 seconds latency (18× faster)
85MB peak memory

Reference data cache hit rate: 93% after warm-up.

For billing operations processing 50,000+ orders monthly, this translated to 8 fewer database instances needed to maintain SLA.

Lessons Learned: The Hard Way

1. Tenant isolation is non-negotiable Initially, we forgot to namespace cache keys by tenant. Customer B got Customer A’s charge definitions. Learned: always include TenantId in cache keys. Make it loud in code reviews.

2. Don’t cache entities with mutable relationships Caching a TransportOrder with its full Charges collection was a mistake—charges update independently. Cache immutable reference data only (ChargeDefinition, VATDefinition). Cache mutable domain objects via query-result caching instead (a different pattern).

3. Batch operations need cache disabling During billing document generation, we read 10,000 charge definitions. Cache lookups themselves became a bottleneck. Solution: tenantService.DisableAuditAndCaching() during batch pivots, then warm the cache post-batch.

4. Expiration strategy is a tuning knob We set everything to 1-hour TTL. Charge definitions rarely change but billing happens hourly. We switched to:

Reference data: 24-hour TTL
Billing reference (VAT, charge definitions): 4-hour TTL
Parent entities: 15-minute TTL

5. Serialization performance matters JsonProperty attributes for enums and nested objects must exclude circular references. Use [JsonIgnore] on back-references.

Gotchas and Disclaimers

Versioning: This pattern works on EF Core 8+, .NET 9. Earlier versions lack some reflection optimizations.
Distributed cache: Requires Redis or Azure Cache for Redis. In-memory caching defeats multi-instance deployment.
Stale data: Cache invalidation is eventual. If real-time consistency is critical (billing cutoff), read from DB directly.
Monitoring: Add metrics for cache hit/miss ratios per entity type. Growing miss rates signal TTL tuning needed or invalidation storms.

Next Steps

Start with high-cardinality, low-change reference data (VAT definitions, charge types).
Measure cache hit rates per entity type in production.
Tune TTL based on update frequency and business tolerance for staleness.
Pair with AsSplitQuery() for parent entity graphs to eliminate Cartesian products.

Ready for featured image.

Entity-Framework on ND Teknik

Query Optimization with EF Core's AsSplitQuery: When N-Way Joins Become a Bottleneck

The Problem: Cartesian Explosion

Split Queries: A Different Approach

Building IncludeAll(): Stop Hand-Writing Include Chains

When NOT to Use Split Queries

Profiling: Before and After

Real Scenario: Billing Order Export

Lessons Learned

Gotchas and Disclaimers

Next Steps

Declarative Caching at Scale: Solving N+1 Queries in Multi-Tenant Systems

The Problem: Entity Graphs and the N+1 Nightmare

The Solution: Declarative, Attribute-Driven Caching

Real Implementation: Unit of Work Integration

Solving the Cycle Problem

Real Impact: The Numbers

Lessons Learned: The Hard Way

Gotchas and Disclaimers

Next Steps

Building `IncludeAll()`: Stop Hand-Writing Include Chains