Recentemente fiz uma enquete no LinkedIn com uma pergunta simples para profissionais que trabalham com SQL Server em ambientes VLDB:
“Quando você tem uma janela de manutenção curta e precisa priorizar ações para melhorar a performance do ambiente, o que costuma trazer mais resultado?”
O resultado chamou bastante atenção:
85,7% votaram em Atualização de Estatísticas
14,3% votaram em Rebuild/Reorganize
Isso mostra uma mudança importante na maturidade das operações de banco de dados.
Durante muitos anos, rebuild de índice tornou-se praticamente uma “receita padrão” para qualquer problema de performance. Em muitos ambientes, jobs de manutenção executam rebuild automaticamente sem sequer avaliar se aquele índice realmente precisa da operação.
Mas em ambientes VLDB (Very Large Databases), essa estratégia nem sempre é a mais eficiente e muitas vezes o verdadeiro problema está nas estatísticas desatualizadas.
O ponto central é simples:
O SQL Server toma decisões baseado em estimativas.
E essas estimativas vêm das estatísticas.
O que realmente impacta o plano de execução?
O Query Optimizer utiliza estatísticas para estimar:
- cardinalidade;
- seletividade;
- distribuição dos dados;
- quantidade de linhas esperadas;
- custo dos operadores.
Se essas informações estiverem incorretas, o optimizer pode:
- escolher Nested Loop ao invés de Hash Join;
- utilizar Index Scan quando deveria fazer Seek;
- gerar spills em tempdb;
- errar paralelismo;
- consumir memória de forma inadequada;
- criar memory grants incorretos.
Ou seja:
Mesmo com índices “perfeitos”, estatísticas ruins continuam gerando planos ruins.
A própria Microsoft destaca que as estatísticas são fundamentais para estimativa de cardinalidade e geração de planos eficientes.
O optimizer não lê a tabela inteira para decidir um plano, ele utiliza histogramas e density armazenados nas estatísticas para prever quantas linhas serão retornadas em cada etapa do plano.
E aqui está o grande problema:
Quando a distribuição dos dados muda e as estatísticas não acompanham essa mudança, começam os problemas clássicos:
- estimativa de 1000 linhas retornando 10 milhões;
- operadores inadequados;
- planos regressivos;
- paralelismo incorreto;
- consumo excessivo de memória;
- degradação generalizada de queries.
Em VLDB isso se torna ainda mais crítico porque pequenos erros de estimativa viram desastres de performance.
O mito do REBUILD como solução universal
Muitos DBAs executam rebuild esperando ganho de performance, mas esquecem que o rebuild melhora principalmente:
- fragmentação lógica;
- organização física das páginas;
- densidade das páginas.
Isso ajuda principalmente workloads com alto volume de leitura sequencial.
Porém, em muitos casos de degradação de performance o problema não é o acesso físico aos dados, sim no optimizer que está tomando decisões ruins. E isso normalmente está ligado às estatísticas.
Na prática, um índice extremamente fragmentado ainda pode produzir um plano excelente se o otimizador tiver boas estimativas. Por outro lado, um índice perfeitamente organizado pode continuar degradando a performance se as estatísticas estiverem desatualizadas.
Esse é o ponto que muitos ambientes começam a perceber quando crescem para múltiplos terabytes.
Um detalhe importante sobre rebuild e estatísticas
Vale destacar: o rebuild de índice *atualiza* as estatísticas daquele índice como efeito colateral o que pode dar a falsa impressão de estar resolvendo ambos os problemas simultaneamente, mas ele não atualiza estatísticas de colunas sem índice, nem de índices que ficaram fora da janela de manutenção. Em VLDB, usar rebuild como substituto de uma política de atualização de estatísticas é uma troca desvantajosa na maioria dos cenários.
O custo operacional do rebuild em VLDB
Em bancos pequenos, rebuild pode parecer inofensivo.
Mas em VLDB o cenário muda completamente.
Um rebuild pode gerar:
- enorme volume de transaction log;
- crescimento excessivo do arquivo de log;
- pressão de IO;
- aumento elevado de CPU;
- consumo intenso de tempdb;
- bloqueios;
- impacto em replicas Always On;
- maior tempo de backup de log;
- longas janelas de manutenção.
Além disso, rebuild de índices grandes pode levar horas.
Enquanto isso o UPDATE STATISTICS direcionado frequentemente entrega melhora perceptível em minutos e com um custo operacional muito menor.
Em muitos casos, atualizar estatísticas de tabelas críticas gera impacto positivo imediato no Query Optimizer sem necessidade de reconstruir índices enormes.
O Cardinality Estimator e sua dependência das estatísticas
O Cardinality Estimator (CE) é um dos componentes mais importantes do SQL Server. Ele é responsável por prever quantas linhas serão retornadas em cada operador do plano de execução — e toda a tomada de decisão do optimizer depende dessas estimativas.
Quando as estatísticas estão desatualizadas, o CE passa a interpretar o ambiente de forma incorreta. Isso afeta diretamente:
- escolha dos joins;
- uso de paralelismo;
- quantidade de memória reservada;
- ordem de acesso às tabelas;
- custo estimado das operações.
Em outras palavras:
Estatísticas ruins fazem o optimizer tomar decisões ruins. E um optimizer tomando decisões ruins degrada a performance muito antes da fragmentação tornar-se um problema real.
O ponto mais importante: atualização automática nem sempre é suficiente
Muita gente acredita que o AUTO_UPDATE_STATISTICS resolve tudo.
Em VLDB isso raramente é verdade e entender o motivo é fundamental.
O threshold clássico exige que aproximadamente 20% das linhas sejam modificadas para disparar a atualização automática. Em uma tabela com 500 milhões de registros, isso significa que 100 milhões de modificações teriam que ocorrer para disparar o gatilho. Em tabelas que recebem cargas pesadas porém concentradas como partições históricas ou tabelas de staging esse threshold pode nunca ser atingido, mesmo com dados completamente defasados.
A partir do SQL Server 2016 (e do 2014 com a trace flag 2371), o dynamic auto-update threshold melhora esse comportamento ao usar uma escala sub-linear baseada em sqrt(1000 * table_rows). Mesmo assim, em VLDB com alto volume de dados, o threshold dinâmico ainda pode ser insuficiente para garantir estatísticas atualizadas nas tabelas mais críticas.
Por isso, ambientes críticos normalmente precisam de:
- manutenção customizada;
- atualização seletiva;
- priorização baseada em `modification_counter`;
- análise de workload;
- FULLSCAN em objetos estratégicos;
- monitoramento contínuo das estatísticas mais sensíveis.
A DMV abaixo é extremamente útil para identificar estatísticas potencialmente desatualizadas:
SELECT
OBJECT_NAME(s.object_id) AS tabela,
s.name AS estatistica,
sp.last_updated,
sp.rows,
sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE sp.modification_counter > 100000
ORDER BY sp.modification_counter DESC;Essa DMV permite identificar quantas modificações ocorreram desde a última atualização das estatísticas, ajudando na priorização da manutenção.
Observação: o valor 100000 é um ponto de partida o ajuste deve ser feito conforme o throughput do seu ambiente. Em VLDB com alto volume de transações, considere thresholds maiores e cruze o modification_counter com last_updated para priorizar estatísticas que são simultaneamente antigas e muito modificadas.
Então rebuild não é importante?
Claro que é.
Rebuild continua sendo extremamente importante em diversos cenários, principalmente quando existe degradação física relevante nos índices.
Mas o mercado está percebendo algo importante:
Em muitos ambientes VLDB, estatísticas impactam mais a qualidade do plano de execução do que fragmentação impacta a leitura física.
Rebuild deve ser tratado como uma ação cirúrgica e não como rotina universal para qualquer problema de performance.
Na prática:
- Índices ajudam o acesso aos dados.
- Estatísticas ajudam o optimizer a escolher o caminho correto.
E em ambientes VLDB, escolher corretamente normalmente vale muito mais do que simplesmente reorganizar páginas.
Referências
Excelente artigo do Pedro Galvão abordando estatísticas e utilização de sys.stats e sys.dm_db_stats_properties:
Documentação Microsoft: sys.dm_db_stats_properties