EF Core 11 introduce una optimización que mejora el rendimiento de las consultas que usan AsSplitQuery. Por defecto, Entity Framework Core carga los datos en una sola consulta, pero al incluir colecciones mediante Include genera JOINs que duplican filas del padre. AsSplitQuery resuelve ese problema ejecutando una consulta por cada colección, aunque a costa de más roundtrips y de una posible inconsistencia de datos, ya que no se trata de una operación atómica.
El problema de fondo, documentado en el issue de GitHub dotnet/efcore#29182, afectaba a las consultas con una navegación de referencia y otra de colección. Hasta EF Core 10, la consulta que recuperaba los Posts incluía también un JOIN con BlogType y ordenaba por su identificador, algo innecesario porque para emparejar un Post con su Blog basta con la clave primaria. Con varias navegaciones de referencia, cada colección arrastraba JOINs y columnas de ORDER BY redundantes, penalizando el plan de ejecución.
Desde la preview 3, EF Core 11 recorta las navegaciones de referencia de las consultas de colección, generando un SQL similar al que un desarrollador escribiría a mano. Las pruebas de rendimiento del autor con SQLite y 5.000 blogs con 5 posts cada uno muestran un tiempo medio de 68,53 ms en .NET 10 frente a 62,07 ms en .NET 11, con asignaciones de memoria que pasan de 33,35 MB a 30,15 MB. El autor advierte de que en la comparativa se cambiaron dos variables (EF 10 sobre .NET 10 y EF 11 sobre .NET 11), por lo que parte de la ganancia podría atribuirse al runtime, aunque considera improbable que la mejora se deba solo a .NET 11.