Desarrollador Java: pregunta de entrevista
¿Cómo evitas consultas N+1 en JPA?
N+1 ocurre cuando una consulta carga padres y el acceso lazy lanza una consulta por cada uno; resuélvelo con fetch join, entity graph, batch fetching o una proyección adecuada.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
Las asociaciones lazy se cargan en el primer acceso, así que iterar sobre cien pedidos y leer order.getCustomer() lanza una consulta para los pedidos y cien más para los clientes. La solución depende del caso: un JOIN FETCH en JPQL o un @EntityGraph carga la asociación en la misma consulta, @BatchSize o hibernate.default_batch_fetch_size convierte las cien consultas en unas pocas con IN, y una proyección a DTO evita las entidades por completo en pantallas de solo lectura. Activar el log de SQL o las estadísticas de Hibernate en pruebas expone el problema antes que producción.
Ejemplo
Un informe que lista pedidos con nombres de cliente pasó de 101 consultas a una tras cambiar el método del repositorio a @Query("select o from Order o join fetch o.customer"). Para un endpoint que necesita pedidos más dos colecciones, dos fetch join producirían un producto cartesiano, así que la segunda colección usa batch fetching.
Errores frecuentes
- Pasar todo a carga EAGER y traer el grafo completo de objetos en cada consulta.
- Hacer fetch join de varias colecciones y multiplicar las filas.
- Detectar el problema solo por la latencia en producción en lugar de afirmar el número de consultas en pruebas.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.