Como você rastrearia e corrigiria um problema de N+1 queries numa aplicação Django?

Confirme primeiro contando queries, usando o Django Debug Toolbar localmente ou assertNumQueries num teste. O padrão é um loop tocando um objeto relacionado, o que dispara uma query por linha porque querysets são preguiçosos. Corrija relações diretas com select_related, que faz um join, e relações reversas ou muitos para muitos com prefetch_related, que roda uma query extra.

Medir vem primeiro, porque chutar performance de ORM é desperdiçar uma tarde. Localmente eu ligo o debug toolbar ou logo as queries em nível debug, e se já está em produção eu olho o trace, onde um endpoint disparando quatrocentos selects quase idênticos é inconfundível. A causa é que um queryset não bate no banco até você iterar, e acessar uma chave estrangeira em cada linha busca aquela relação preguiçosamente. Para uma chave estrangeira direta eu adiciono select_related, que vira um join e uma query só. Para relações reversas ou muitos para muitos eu uso prefetch_related, que dispara uma segunda query e costura os resultados em Python. Depois de corrigir, eu escrevo um teste embrulhando a view em assertNumQueries com o número esperado, porque senão a próxima pessoa adiciona um campo no template e aquilo regride em silêncio. Num dashboard interno a gente levou uma página de cerca de trezentas queries para quatro, e o tempo de carga foi de uns dois segundos para menos de duzentos milissegundos.