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. 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. 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. 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. Con los logs habilitados: builder.Services.AddDbContext(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. 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. 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. 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. 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. Problema Síntoma Solución ToList() prematuro SELECT * sin WHERE, todo en memoria Mantener IQueryable hasta el final SELECT * silencioso Proyección ignorada, columnas de más Expresiones traducibles en Select N+1 Una query por cada registro del loop Include o proyección con Select Explosión cartesiana Una query lenta con filas multiplicadas AsSplitQuery o proyección con Select 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. 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.