System Design/02 - Componentes/Caching2 min
Database Caching
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Cache dentro do próprio banco, geralmente sem você configurar nada — e por isso frequentemente ignorado nas discussões de performance.
| Mecanismo | O que guarda |
|---|---|
| Buffer pool / shared buffers | Páginas de dados e índice em RAM — o mais importante |
| Plan cache | Planos de execução já compilados |
| Result cache | Resultado de queries idênticas (varia por banco) |
| Materialized view | Resultado pré-computado e persistido (Materialized View) |
| Cache do SO | Páginas de arquivo abaixo do banco |
O buffer pool é o que decide o desempenho real: se o working set cabe na RAM, o banco quase não toca o disco. Se não cabe, cada leitura vira I/O — e a diferença é de ordens de grandeza.
Trade-offs
A intervenção de maior retorno costuma ser dar mais RAM ao banco antes de adicionar Redis na frente. Um buffer pool bem dimensionado resolve o problema sem introduzir invalidação, sem mais um componente e sem risco de inconsistência.
O que o cache do banco não resolve: ele economiza I/O, não CPU. Uma query com JOIN pesado e agregação continua cara mesmo com tudo em memória — aí o cache útil é Application Caching guardando o resultado, não as páginas.
Também não resolve o custo de rede e de conexão: cada consulta ainda atravessa o pool, o parser e o planejador.
Query result cache (o antigo query cache do MySQL, removido na versão 8) tem um problema estrutural: qualquer escrita na tabela invalida todas as entradas relacionadas. Sob carga de escrita, o cache passa mais tempo se invalidando do que servindo.
Materialized view é a forma mais sólida de cache no banco — resultado persistido, atualizado sob demanda ou por trigger. O trade-off é frescor contra custo de atualização.
Exemplo prático
Uma query de dashboard leva 8 segundos.
Primeira hipótese, testada primeiro: o índice existe? Uma query sem índice fazendo sequential scan não melhora com cache nenhum — ela lê a tabela inteira todas as vezes.
Segunda: o working set cabe no buffer pool? Se o cache hit ratio do banco está em 60%, aumentar a RAM pode resolver sozinho.
Só então vale cachear o resultado na aplicação. A ordem importa: cachear uma query mal escrita esconde o problema e mantém o custo — e o primeiro miss depois de um deploy revela que ele nunca foi resolvido.
Relacionado
Parte de Caching · roadmap.sh/system-design