O que é o problema de N mais um queries e como você o resolve?

Você roda uma query para buscar uma lista, depois percorre as linhas e dispara outra query por linha, então 200 posts viram 201 idas e voltas. Resolva carregando as linhas relacionadas em uma passada só: um join, uma query com IN indexada pelo id do pai, ou um loader de batch que junta os ids dentro de um tick da requisição. O sinal é a latência crescendo linearmente com a quantidade de resultados enquanto cada query individual parece rápida.

Isso normalmente aparece no momento em que alguém renderiza uma lista. Você busca os pedidos, depois no template você toca em order.customer.name, e o ORM dispara em silêncio uma query por linha. Individualmente aquilo é meio milissegundo, então nada parece quebrado até a lista crescer e o endpoint levar quatro segundos. Eu detecto olhando a contagem de queries por requisição em vez da duração das queries; a maioria das ferramentas de APM mostra isso direto, e localmente eu ligo o log de queries e conto. A correção depende do formato. Para uma relação simples do tipo pertence a, um eager load ou um join resolve. Para um um para muitos em que o join multiplicaria linhas, eu prefiro uma segunda query com uma cláusula IN e costurar na memória. Em uma API GraphQL tem que ser um dataloader, porque os resolvers não fazem ideia de que estão sendo chamados em lote. O que eu evito é carregar tudo de forma antecipada por padrão, já que isso troca um problema por puxar meio banco para a memória.