EF Core: La explosión cartesiana — Hiciste todo bien y aun así el query es un desastre

En el artículo anterior vimos el problema N+1: queries dentro de loops que se multiplican con los datos. La solución que aprendiste fue usar Include para cargar las relaciones en una sola query.

Eso es correcto. Hasta que tienes más de una colección relacionada en el mismo nivel.

El escenario: un Include razonable que se vuelve un problema

Tienes pedidos. Cada pedido tiene un cliente, una lista de productos y una lista de pagos. Quieres cargar todo en una sola operación para evitar el N+1:

var pedidos = await context.Pedidos
    .Include(p => p.Cliente)
    .Include(p => p.Productos)
    .Include(p => p.Pagos)
    .Where(p => p.FechaCreacion >= hace30Dias)
    .ToListAsync();

Tres Include. Se ve limpio, se ve correcto. EF Core lo acepta sin quejarse.

Pero el SQL que genera no es lo que imaginas.

Lo que EF Core hace por debajo

El problema aparece específicamente cuando incluyes múltiples colecciones “hermanas” en el mismo nivel del grafo de navegación. Es importante distinguirlo de ThenInclude, que normalmente no genera este problema:

// Caso problemático: dos colecciones en el mismo nivel
.Include(p => p.Productos)
.Include(p => p.Pagos)

// Normalmente no problemático: navegación en profundidad
.Include(p => p.Productos)
    .ThenInclude(pr => pr.Categoria)

Cuando EF Core genera un JOIN para cada colección hermana, el resultado no produce una fila por pedido — produce una fila por cada combinación posible entre los registros relacionados.

Si un pedido tiene 5 productos y 3 pagos, el resultado del JOIN tiene 15 filas para ese pedido. EF Core las lee todas y reconstruye el objeto en memoria, pero la base de datos procesó y transfirió 15 filas donde conceptualmente había 1.

El crecimiento es cartesiano: cada colección multiplica las filas del resultado. Con 100 pedidos, cada uno con 10 productos y 5 pagos, el resultado no son 100 filas — son 5,000 filas que viajan de la base de datos a tu servidor para que EF Core las reduzca de vuelta a 100 objetos.

Eso es la explosión cartesiana.

Cómo detectarlo

El warning de EF Core

Cuando EF Core detecta este patrón, emite un warning en los logs:

Compiling a query which loads related collections for more than
one collection navigation, either via 'Include' or through
projection. Please review the generated SQL and inspect whether
the cartesian explosion might negatively impact performance.

Si ves este mensaje en tus logs y lo ignoraste, es probable que ya tengas este problema en alguna query.

Los tiempos que no tienen proporción

Con los logs habilitados:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information));

Verás algo así:

Executed DbCommand (847ms) [Parameters=[@p0='2025-02-14'], CommandType='Text', CommandTimeout='30']
SELECT p.Id, p.Total, ...
FROM Pedidos p
LEFT JOIN Clientes c ...
LEFT JOIN PedidoProductos pr ...
LEFT JOIN Pagos pa ...
WHERE p.FechaCreacion >= @p0

Una sola query, pero 847ms. Con pocos datos en dev tal vez son 12ms y nadie lo cuestiona. Con datos reales de producción el tiempo empieza a crecer de forma que no tiene proporción con el número de registros que devuelve el endpoint.

A diferencia del N+1, aquí solo hay una query. Si solo cuentas queries, todo parece correcto. Lo que tienes que mirar es cuántas filas devuelve esa query.

La solución: AsSplitQuery

EF Core 5 introdujo AsSplitQuery precisamente para este caso. En lugar de un solo JOIN que produce el producto cartesiano, EF Core ejecuta una query separada por cada Include y ensambla los resultados en memoria:

var pedidos = await context.Pedidos
    .Include(p => p.Cliente)
    .Include(p => p.Productos)
    .Include(p => p.Pagos)
    .Where(p => p.FechaCreacion >= hace30Dias)
    .AsSplitQuery()
    .ToListAsync();

Las queries que se ejecutan ahora:

-- Query 1: los pedidos con el cliente
SELECT p.Id, p.Total, p.FechaCreacion, c.Id, c.Nombre
FROM Pedidos p
LEFT JOIN Clientes c ON p.ClienteId = c.Id
WHERE p.FechaCreacion >= '2025-02-14'

-- Query 2: los productos de esos pedidos
SELECT pr.Id, pr.Nombre, pr.Precio, pr.PedidoId
FROM PedidoProductos pr
WHERE pr.PedidoId IN (1, 2, 3, ...)

-- Query 3: los pagos de esos pedidos
SELECT pa.Id, pa.Monto, pa.FechaPago, pa.PedidoId
FROM Pagos pa
WHERE pa.PedidoId IN (1, 2, 3, ...)

Tres queries en lugar de una, pero cada una devuelve exactamente las filas que necesita. Sin producto cartesiano, sin filas duplicadas.

AsSplitQuery no es siempre la respuesta

Vale la pena entender cuándo usarlo y cuándo no:

Úsalo cuando:

• Tienes múltiples Include de colecciones hermanas
• Los tiempos de query son desproporcionados respecto al número de registros que devuelves
• El warning de EF Core aparece en tus logs

No lo uses cuando:

• Solo tienes un Include — el producto cartesiano no ocurre con una sola colección
• Necesitas consistencia transaccional estricta — las queries de AsSplitQuery se ejecutan por separado y en teoría otro proceso podría modificar datos entre una y otra
• El conjunto de datos es pequeño — el overhead de múltiples queries puede ser mayor que el beneficio

Una advertencia sobre paginación: si usas AsSplitQuery junto con Skip/Take, asegúrate de tener un OrderBy estable y con un campo único. Sin eso, los resultados entre las queries separadas pueden ser inconsistentes.

El Include que no hace nada

Antes de cerrar, vale la pena mencionar un hábito relacionado que ocurre con frecuencia.

Muchos developers agregan Include de forma defensiva — para asegurarse de que las propiedades de navegación no sean null. Tiene sentido cuando materializas la entidad completa. Pero cuando proyectas a un DTO con Select, EF Core ignora completamente los Include:

// ❌ Los Include son ignorados — EF Core no materializa Pedido
var pedidos = await context.Pedidos
    .Include(p => p.Cliente)      // ignorado
    .Include(p => p.Productos)    // ignorado
    .Include(p => p.Pagos)        // ignorado
    .Where(p => p.FechaCreacion >= hace30Dias)
    .Select(p => new PedidoDetalleDto
    {
        Cliente = p.Cliente.Nombre,
        Total = p.Total,
        Productos = p.Productos.Select(pr => pr.Nombre).ToList(),
        TotalPagado = p.Pagos.Sum(pa => pa.Monto)
    })
    .ToListAsync();

EF Core resuelve los JOINs necesarios directamente desde la proyección del Select. Los Include no aportan nada — ni errores, ni beneficios, ni SQL adicional. Lo mismo aplica para AsSplitQuery: si proyectas a un DTO, no hay entidades que materializar, así que tampoco tiene efecto.

El código funciona igual con o sin ellos. El problema es que quien lo lee después asume que son necesarios, y esa confusión se acumula.

La proyección con Select como alternativa

Cuando no necesitas materializar la entidad completa, la proyección con Select puede ser más eficiente que AsSplitQuery. En muchos casos permite a EF Core generar SQL mucho más eficiente y evitar la materialización completa de relaciones:

// ✅ Sin Include, sin AsSplitQuery
var pedidos = await context.Pedidos
    .Where(p => p.FechaCreacion >= hace30Dias)
    .Select(p => new PedidoDetalleDto
    {
        Cliente = p.Cliente.Nombre,
        Total = p.Total,
        Productos = p.Productos.Select(pr => pr.Nombre).ToList(),
        TotalPagado = p.Pagos.Sum(pa => pa.Monto)
    })
    .ToListAsync();

La regla general: usa Include cuando materialices la entidad. Usa Select cuando trabajes con DTOs.

Resumen

Si no ves el SQL que EF Core genera, no sabes lo que está pasando. Los logs son la herramienta más simple y más ignorada para detectar estos problemas antes de que lleguen a producción.

¿Has tenido que resolver una explosión cartesiana en producción? ¿Cómo lo detectaste? Cuéntame en los comentarios.

¿Qué sigue?

En el próximo artículo vamos a hablar de algo que EF Core hace en todas tus consultas sin que lo hayas pedido: rastrear cada entidad que lees para detectar cambios. En pantallas de solo lectura estás pagando ese costo en memoria y CPU sin obtener nada a cambio — y con suficientes datos, se nota.