Administração de Bancos de Dados
04. Otimização e desempenho em larga escala
4º capítulo da apostila Administração de Bancos de Dados: explicação contínua e em linguagem simples sobre Otimização e desempenho em larga escala, com exemplos, conexões e mapa mental.
Neste capítulo · 12 seções⌄
Uma consulta lenta é um sintoma, não um diagnóstico. O caminho de investigação passa pelo plano de execução, volume, seletividade, estatísticas, índices e forma da consulta antes de chegar a mudanças de arquitetura.
Com o modelo e a linguagem estabelecidos, passamos a cuidar do banco em funcionamento. A sequência liga governança, arquitetura interna, transações, desempenho, observabilidade, segurança, recuperação e soluções em memória. Este é o capítulo 4 de 8 da disciplina Administração de Bancos de Dados. A leitura retoma Transações: propriedades ACID e controle de concorrência e usa essa base para avançar. Depois, seguiremos para Monitoração e observabilidade de bancos de dados.
O fio condutor
Banco de dados deve ser estudado como um sistema de decisões conectadas. O significado atribuído ao dado orienta o modelo; o modelo condiciona consultas e atualizações; o SGBD executa essas operações sob regras de segurança, concorrência, desempenho e recuperação. Quando uma dessas camadas muda, as demais podem ser afetadas.
Ao longo da leitura, acompanhe sempre quatro perguntas: qual problema está sendo resolvido, qual estrutura representa o problema, que garantia precisa ser preservada e qual custo acompanha a escolha. Esse roteiro ajuda a compreender os conceitos em vez de apenas memorizar nomes.
Diagnóstico
Começamos por Diagnóstico, pois essa base permite compreender as decisões apresentadas nas seções seguintes.
O `EXPLAIN` mostra o plano escolhido: tipo de acesso a cada tabela (varredura sequencial ou por índice), ordem e algoritmo de junção e custo estimado. O EXPLAIN ANALYZE vai além e executa a consulta, comparando estimativa e tempo real — divergência grande entre as duas é sinal de estatística desatualizada.
E nem todo gargalo é de CPU, memória ou I/O: muitas sessões bloqueadas esperando locks retidos por transações longas produzem lentidão com hardware ocioso. Esse diagnóstico se faz olhando transações e bloqueios, não gráficos de recurso.
Repare como EXPLAIN e ANALYZE, Estatísticas do otimizador, Nem todo gargalo é hardware participam da mesma decisão. Ao relacionar esses elementos, fica mais fácil prever o comportamento do banco e reconhecer os efeitos de cada escolha.
Índices na prática
A seção anterior apresentou Diagnóstico. Agora chegamos a Índices na prática, que acrescenta a próxima peça do mesmo raciocínio.
Continue lendo de graça
O capítulo inteiro está liberado no plano gratuito
Criar conta leva menos de um minuto e não pede cartão. Você destrava o texto completo, o mapa mental, o PDF para estudar off-line e ainda resolve questões inéditas todo dia.
Leu o resumo? Agora pratique.
São 60 questões inéditas de Otimização e desempenho em larga escala, todas comentadas alternativa por alternativa.
Você volta para este capítulo depois de criar a conta.
Fontes consultadas
- Documentação oficial do PostgreSQL (EXPLAIN, ANALYZE, índices, particionamento, CREATE INDEX … INCLUDE) e do SQL Server
- Elmasri & Navathe, Sistemas de Banco de Dados — processamento e otimização de consultas
- Silberschatz, Korth & Sudarshan, Sistema de Banco de Dados
- Documentação do Apache Parquet, Apache ORC e Apache Spark (broadcast join, skew)
- Acervo comentado de Banco de Dados — Otimização e desempenho em larga escala (60 questões publicadas), conferido em 14/09/2026