Otimização de desempenho

Desde a primeira lição, um mesmo defeito se repete: uma lista carregada em uma consulta e, em seguida, uma consulta por elemento para completar os dados que faltam. Cinquenta pedidos exibidos, cento e uma consultas emitidas. O código Java é irrepreensível, as anotações são as da documentação, os testes passam. E a página leva oito segundos para ser exibida em produção.

Este capítulo é o desfecho. Ele começa pelo diagnóstico, porque não se pode corrigir o que não se mede, e porque a intuição erra sistematicamente nesse ponto: a consulta cara quase nunca é a que suspeitamos. Em seguida, apresenta as três ferramentas que resolvem o N+1 — JOIN FETCH, @EntityGraph, @BatchSize — com o critério que permite escolher entre elas, pois não são intercambiáveis e cada uma tem um limite rígido.

Depois vem o caso que o JOIN FETCH não sabe tratar: a paginação sobre uma coleção carregada. É uma armadilha específica e silenciosa, que faz carregar a tabela inteira em memória enquanto um aviso discreto passa despercebido nos logs.

A lição termina com aquilo que nenhuma anotação substitui: os índices do PostgreSQL, que a geração de esquema não cria, e sem os quais todas as otimizações anteriores incidem sobre uma varredura sequencial da tabela.