Como otimizar agregações lentas em uma tabela grande?

Question

IT Interview Practice · Accepted Answer

Para otimizar uma agregação lenta, identifique primeiro **o significado do resultado e qual operação consome tempo**. Uma agregação combina linhas em um resumo, como receita por vendedor. Seu custo depende do volume lido e combinado.

Considere um painel com a receita do mês anterior. Use esse exemplo para decidir entre melhorar a consulta, armazenar um resumo preparado ou mover os relatórios.

## 1. Confirme a resposta antes de acelerá-la

Esclareça se receita significa pedidos pagos ou criados, como os reembolsos entram no cálculo e quais moedas estão incluídas. Pergunte também quão atualizado o painel precisa ser. Isso altera a consulta e as otimizações disponíveis.

Um erro comum é juntar um pagamento a vários itens do pedido e depois somar o valor do pagamento:

```text
[Payment: 100] -> [Join with 3 items] -> [100, 100, 100]
                                               |
                                          [SUM = 300]
```

Os números são ilustrativos. A consulta multiplicou o pagamento; acelerá-la apenas retorna um total incorreto mais rapidamente. Agregue no nível de negócio pretendido ou altere o join antes de avaliar desempenho.

## 2. Localize a parte cara da execução

O plano de execução mostra as operações usadas para obter o resultado. Examine etapas caras e seus volumes de entrada, em vez de presumir que falta apenas outro índice.

| Observação | Pergunta a investigar |
| --- | --- |
| Muitas linhas irrelevantes são lidas | Filtros ou eliminação de partições podem excluí-las? |
| A contagem real diverge muito da estimativa | As estatísticas representam esses dados? |
| Um join repete trabalho muitas vezes | Sua entrada é grande demais ou o acesso é inadequado? |
| Agrupamento ou ordenação grava dados temporários em disco | É possível reduzir a entrada antes de aumentar a memória? |

No PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) executa a consulta e informa seu comportamento real. Faça uma investigação cara em ambiente controlado ou com um orçamento deliberado de recursos em produção. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Reduza trabalho no banco atual

Para o painel, selecione o mês e as colunas necessários. Verifique se o plano realmente ignora partições irrelevantes e se os joins trazem dados dispensáveis para o resumo.

Um índice ajuda quando evita leitura suficiente. Se o relatório precisa da maioria das linhas, uma varredura sequencial pode ser adequada. Julgue o plano resultante e o custo medido, não apenas a presença de um índice.

Se a ordenação usa disco por falta de memória, reduzir sua entrada pode resolver. Aumentar memória por consulta pode esgotar a RAM quando vários relatórios rodam juntos. Teste com concorrência representativa.

## 4. Decida se vale preparar o resultado antecipadamente

Quando muitos usuários pedem os mesmos totais e algum atraso é aceitável, varrer pedidos brutos repetidamente desperdiça trabalho. Uma tabela de resumos pode guardar totais por dia, vendedor e moeda; o painel combina esses resultados menores.

```text
[Orders] -> [Scheduled / incremental calculation]
                              |
                       [Daily summaries] -> [Dashboard]
```

O benefício vem de executar cálculos compartilhados uma vez, em vez de a cada requisição. Uma materialized view também armazena resultados de consulta, com seu próprio comportamento de atualização.

Essa economia traz responsabilidades:

- Defina a frequência de atualização e mostre ao usuário a atualidade relevante.
- Aplique reembolsos, pedidos atrasados e correções sem dupla contagem.
- Garanta reprocessamento seguro e uma forma de reconstruir os resumos.
- Guarde soma e contagem ao combinar médias; a média das médias pode estar errada.

Para este painel, resumos preparados só são candidatos se a atualização e as correções atenderem ao requisito do primeiro passo.

## 5. Separe relatórios quando as medições justificarem

Se varreduras analíticas amplas continuam caras e interferem nas compras, avalie um armazenamento analítico adequado. Inclua atraso de sincronização, recuperação e custo de operar outro sistema.

Uma réplica de leitura pode isolar a carga dos relatórios, mas a mesma consulta pode continuar cara nela. A separação muda onde o custo ocorre; não necessariamente o elimina.

Compare cada alteração com um resultado confiável e a mesma carga de teste. Verifique tempo de resposta, recursos, atualidade e impacto nas escritas.

**Lembre-se:** resultado correto → gargalo medido → menos trabalho desnecessário → resumos preparados se adequados → análise separada se ainda necessária.

Observação	Pergunta a investigar
Muitas linhas irrelevantes são lidas	Filtros ou eliminação de partições podem excluí-las?
A contagem real diverge muito da estimativa	As estatísticas representam esses dados?
Um join repete trabalho muitas vezes	Sua entrada é grande demais ou o acesso é inadequado?
Agrupamento ou ordenação grava dados temporários em disco	É possível reduzir a entrada antes de aumentar a memória?

1. Confirme a resposta antes de acelerá-la

2. Localize a parte cara da execução

3. Reduza trabalho no banco atual

4. Decida se vale preparar o resultado antecipadamente

5. Separe relatórios quando as medições justificarem

Perguntas relacionadas