Optimización del rendimiento

Desde la primera lección, un mismo defecto no deja de aparecer: una lista cargada con una consulta y, después, una consulta por elemento para completar los datos que faltan. Cincuenta pedidos mostrados, ciento una consultas emitidas. El código Java es impecable, las anotaciones son las de la documentación, las pruebas pasan. Y la página tarda ocho segundos en mostrarse en producción.

Este capítulo es el desenlace. Empieza por el diagnóstico, porque no se puede corregir lo que no se mide, y porque la intuición se equivoca sistemáticamente en este punto: la consulta costosa casi nunca es la que uno sospecha. A continuación presenta las tres herramientas que resuelven el N+1 —JOIN FETCH, @EntityGraph, @BatchSize— junto con el criterio para elegir entre ellas, ya que no son intercambiables y cada una tiene un límite estricto.

Después viene el caso que JOIN FETCH no sabe tratar: la paginación sobre una colección cargada. Es una trampa específica y silenciosa, que hace cargar toda la tabla en memoria mientras una discreta advertencia desfila por los registros.