Si eres developer y trabajas con .NET, lo más probable es que en algún momento hayas caído rendido ante LINQ. Lo entiendo, es tentador cual canto de sirena. Tiene lo suyo: expresividad, fluidez, integración total con C#… es cómodo. Pero si trabajas con SQL Server como motor de datos, más te vale saber qué está haciendo LINQ por detrás. Porque aquí, en las profundidades del motor, no nos tragamos la excusa de «yo sólo puse un .Where()».
Este artículo no es para demonizar LINQ. Es para que entiendas, desde el punto de vista del DBA que va a recibir tus consultas, por qué usar LINQ sin saber cómo funciona es como lanzar T-SQL con los ojos cerrados y esperar que salga rápido. Alerta spoiler: no lo hace.
LINQ: el ORM moderno que no siempre sabe lo que hace
A ti LINQ te permite escribir consultas con tipos, IntelliSense, lambdas y toda la fantasía moderna del desarrollo elegante. A nosotros nos llega una consulta SQL que ha generado un ORM sin ningún sentido del rendimiento, de los índices ni del plan de ejecución.
Tú ves:
var pedidos = context.Pedidos
.Where(p => p.Cliente.Pais == "España")
.OrderBy(p => p.Fecha)
.ToList();Nosotros vemos: joins sin sentido, LEFT OUTER JOIN innecesarios, condiciones que no usan índices, y a veces hasta SELECT TOP 1000000 porque alguien no quería paginar como es debido. Lo que para ti es una consulta sencilla, para nosotros puede ser una fiesta de bloqueos, CPU y discos saturados.
LINQ no es malo. Pero no sabe optimizar. Y su traductor a SQL (ya sea EF, LINQ to SQL o el flavor de turno) sólo tiene una misión: funcionar. No rendir. Eso, amigos, es responsabilidad vuestra.
SQL Server no es una caja negra
Si has trabajado toda tu vida con Entity Framework sin mirar lo que genera por debajo, te estás perdiendo la mitad de la película. Y no la buena. SQL Server es un motor potente, flexible y bastante generoso… pero sólo cuando le das instrucciones claras.
Cuando llega una consulta LINQ traducida automáticamente, SQL Server hace lo que puede. Pero si la estructura de la consulta es compleja, el uso de joins es arbitrario y los filtros se aplican después del .ToList(), entonces no hay milagros. Hay “table scans”, “sort warnings”, “hash matches” no deseados y todo lo que un DBA no quiere ver en el plan de ejecución.
Lo que tú ves como un .Include() para cargar relaciones, nosotros lo vemos como una máquina de hacer JOINs sin control. Y cuando eso se hace en producción con datos reales, hay que estar muy seguro de que se entiende lo que se está mandando.
IEnumerable, IQueryable y el horror que no ves en LINQ
Hay un detalle que seguimos viendo incluso en equipos senior: no distinguir IEnumerable de IQueryable a la hora de consultar.
Cuando usas IQueryable, la consulta se traduce a SQL y se ejecuta en la base de datos. Bien. Pero cuando haces .ToList() antes de aplicar más filtros, estás trayendo todo a memoria y filtrando en .NET. Eso está bien si tienes diez registros. Si tienes diez millones, acabas de llenar el servidor de aplicaciones con datos que no necesitabas.
El ORM no sabe optimizar. Tú sí deberías.
Así que cuando alguien hace esto:
var pedidos = context.Pedidos.ToList();
var pedidosFiltrados = pedidos.Where(p => p.Importe > 1000);Y luego se pregunta por qué la aplicación va lenta, la respuesta es clara: no es la base de datos, es tu código. LINQ puede ser declarativo, pero no mágico.
Los casos en que LINQ hace llorar al optimizador
¿Sabes lo que pasa cuando encadenas tres .Include()s, haces un .SelectMany() y luego aplicas una condición que sólo puede evaluarse en cliente? Que el SQL resultante se convierte en un engendro. Y a nosotros nos llega una consulta de 150 líneas con subconsultas, columnas que no se usan y JOINs en cascada que anulan los índices.
Esto no es una exageración. Lo he visto con mis propios ojos. Y no una vez. Las herramientas modernas de desarrollo facilitan mucho la creación de consultas… que nadie ha revisado. Y luego cuando llegan las quejas de rendimiento, el culpable nunca es el ORM. Siempre es “la base de datos que no escala”.
No. La base de datos escala. Lo que no escala es traducir expresiones lambda como si fueran instrucciones optimizadas para un motor relacional.
Cómo hacer las paces: consejos para developers (sí, es por vuestro bien)
Lo primero: aprende a ver el SQL que estás generando. EF Core permite interceptar y registrar el SQL generado. Úsalo. Lee ese SQL. Míralo con ojos críticos. Si ves que tiene 10 joins, 30 columnas innecesarias y ninguna cláusula WHERE, no lo envíes a producción. Mándalo al infierno de staging, a ver cuánto tarda.
Segundo: si una consulta es crítica, escribe SQL tú mismo. Usa FromSqlRaw() o, mejor aún, procedimientos almacenados dentro de SQL Server. No pasa nada. No es “menos elegante”, es más responsable.
Tercero: si tienes dudas, habla con el DBA. No somos ogros. Bueno, algunos sí. Pero en general, preferimos una conversación a tener que cazar queries con el SQL Profiler porque ha saltado una incidencia de rendimiento a las 3 de la mañana.
Cuarto: entiende el modelo de ejecución diferida de LINQ. Y si tienes que filtrar, hazlo antes del .ToList(). Siempre.
Y por último: no abuses del azúcar sintáctico. LINQ puede ser cómodo, pero no sustituye al conocimiento. No saber lo que está pasando en SQL Server es como conducir un coche sin saber si vas en primera o en tercera.
¿Cuándo sí usar LINQ?
LINQ brilla en consultas simples. En operaciones sobre colecciones en memoria. En proyecciones pequeñas y bien definidas. Si tu consulta es trivial y los datos están bien indexados, no hay problema. Pero si estás construyendo un informe complejo, una API con cientos de miles de registros o una consulta crítica para el negocio, deja de lado la comodidad.
Y si usas LINQPad, mejor. Ahí sí puedes ver lo que pasa y ajustar con cabeza. Porque en el fondo, LINQ no es el problema. El problema es no saber cuándo dejar de usarlo.
Conclusión: hay vida más allá de LINQ
No hay escapatoria. Si trabajas en un proyecto con SQL Server, y usas un ORM o LINQ, el rendimiento de tus consultas depende de ti. No vale decir “eso es cosa del DBA” o “es que eso lo hace el ORM solo”. Porque cuando la aplicación se arrastra, da igual de quién sea la culpa: hay que arreglarlo y ni todo el hardware del mundo arregla depende que consultas.
Así que la próxima vez que escribas una consulta LINQ, pregúntate: ¿qué SQL va a salir de aquí? ¿Lo he mirado? ¿Lo he probado con datos reales? ¿Estoy filtrando bien? ¿Estoy trayendo sólo lo que necesito?
Y si no puedes responder a eso con seguridad, tal vez lo mejor sea bajarse al T-SQL y escribir como los mayores.
Porque aquí no se trata de gustos. Se trata de no matar al servidor con buenas intenciones y malas queries.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
