A Mentira Sobre Fragmentação de Índices no SQL Server: O Problema Não Acabou com SSD
Durante muitos anos, fragmentação de índices era praticamente um pesadelo no SQL Server.
Quem trabalhou na época de discos HDD lembra perfeitamente disso.
Os discos mecânicos dependiam fortemente de leitura sequencial.
Quando os índices ficavam fragmentados, o braço mecânico do disco precisava “saltar” entre páginas espalhadas fisicamente.
Resultado:
- random I/O alto
- scans lentos
- throughput destruído
- queries sofrendo absurdamente
Naquela época, rebuild de índice realmente fazia muita diferença.
Só que o cenário mudou completamente.
Hoje temos:
- SSD
- NVMe
- SANs modernas
- dezenas ou centenas de GB em memória RAM
- buffer pool gigantesco
E isso mudou radicalmente o impacto da fragmentação.
O que muita gente não percebeu
Muitos DBAs continuam usando a mesma estratégia de 15 anos atrás:
- rebuild acima de 30%
- reorganize acima de 5%
- maintenance plans agressivos
Como se ainda estivéssemos em 2008.
Mas isso já não representa a realidade atual.
O próprio Brent Ozar já falou diversas vezes que fragmentação perdeu grande parte do impacto em SELECTs modernos. (Brent Ozar Unlimited®)
E tecnicamente ele está correto.
Com SSD e grandes quantidades de memória:
- random I/O custa muito menos
- read-ahead continua eficiente
- scans fragmentados muitas vezes têm impacto mínimo
Em muitos casos, o gargalo deixou de ser disco há anos.
Então fragmentação não importa mais?
Importa.
Mas não do jeito que muita gente pensa.
Esse é o ponto que quase ninguém explica corretamente.
A discussão moderna sobre fragmentação não é mais sobre SEEK versus SCAN.
O problema moderno é:
- page density
- page splits
- write amplification
- buffer pool waste
- manutenção de índices durante UPDATE e DELETE
E isso muda completamente a análise.
O ponto que quase ninguém comenta
Existe um detalhe extremamente importante que muitos vídeos simplificam demais:
Fragmentação ainda impacta muito workloads de escrita.
Principalmente:
- UPDATE
- DELETE
- INSERT
- operações OLTP intensivas
Porque fragmentação gera:
- mais páginas
- mais movimentação interna
- mais page splits
- mais manutenção de árvore B-Tree
- mais escrita no transaction log
- mais locks
- mais latch contention
E isso continua extremamente relevante mesmo em SSD. (Microsoft Learn)
O verdadeiro problema moderno: Page Density
A própria Microsoft hoje enfatiza algo importante:
page density muitas vezes importa mais do que fragmentação lógica. (Microsoft Learn)
Quando páginas ficam vazias após:
- DELETEs
- UPDATEs
- splits
o SQL Server precisa:
- ler mais páginas
- manter mais páginas em RAM
- navegar em árvores maiores
Ou seja:
mesmo em memória RAM, índices inchados consomem mais recursos.
E isso impacta diretamente:
- cache efficiency
- CPU
- memory pressure
- throughput de escrita
Por que UPDATE e DELETE sofrem mais?
Porque operações de escrita precisam modificar a estrutura do índice.
Quando o índice está fragmentado:
- existem mais páginas
- menos densidade
- mais movimentação entre páginas
- mais divisão de páginas
Isso aumenta:
- latch waits
- PAGELATCH contention
- geração de log
- locking interno
E em ambientes OLTP isso vira um problema enorme.
Principalmente em:
- ERPs
- sistemas financeiros
- filas
- workloads transacionais pesados
O problema do REBUILD no SQL Server Standard
E aqui chegamos em outro ponto crítico.
No SQL Server Enterprise existe ONLINE INDEX REBUILD.
Mas no SQL Server Standard?
Não.
E isso muda tudo.
Porque um REBUILD offline pega SCH-M Lock.
Ou seja:
bloqueia leitura e escrita durante partes críticas da operação.
Em ambientes movimentados isso pode virar um caos:
- filas travadas
- blocking chain
- timeout
- aplicação congelando
Muita gente roda maintenance job de madrugada sem perceber o impacto.
E pior:
às vezes o rebuild está causando mais problema do que resolvendo.
O lado negativo que quase ninguém mede
Rebuild também:
- explode transaction log
- invalida planos
- atualiza estatísticas
- gera recompilações
- aumenta CPU
- aumenta I/O
E muitas vezes o ganho percebido nem veio da fragmentação.
Veio da atualização de estatísticas. (Reddit)
Isso é extremamente importante.
Muitos ambientes “melhoram” após rebuild simplesmente porque:
- o plano ruim saiu do cache
- estatísticas foram atualizadas
- ocorreu recompilação
Não porque a fragmentação era realmente o problema.
O Brent Ozar está errado?
Não.
Mas a discussão normalmente fica incompleta.
Quando Brent fala que fragmentação pouco impacta SELECT em SSD moderno, ele está absolutamente correto. (Brent Ozar Unlimited®)
O problema é que muita gente interpreta isso como:
“fragmentação não importa mais”.
E isso é falso.
Ela ainda importa muito para:
- escrita
- manutenção de páginas
- densidade
- concorrência
- pressão de memória
- operações OLTP
O maior erro dos DBAs modernos
O erro hoje não é deixar índice fragmentar.
O erro é:
reindexar sem necessidade.
Porque rebuild excessivo:
- gera lock
- gera blocking
- gera log gigantesco
- aumenta CPU
- invalida cache
- cria manutenção desnecessária
E muitas vezes resolve um problema que nem existia.
O que realmente faz sentido hoje
A abordagem moderna precisa ser muito mais inteligente.
Em vez de olhar apenas:
- avg_fragmentation_in_percent
precisa analisar:
- page density
- workload de escrita
- latch contention
- uso de memória
- scans reais
- impacto em waits
- tamanho do índice
- frequência de UPDATE/DELETE
Porque hoje o problema já não é mais simplesmente “página fora de ordem no disco”.
O SQL Server moderno é muito mais complexo do que isso.
Conclusão
Fragmentação mudou de significado.
Na época dos HDDs:
o problema principal era leitura física aleatória.
Hoje:
o problema principal é eficiência estrutural do índice.
SELECTs muitas vezes quase não sofrem mais.
Mas UPDATEs, DELETEs e workloads OLTP continuam sendo altamente impactados por:
- baixa densidade
- page splits
- excesso de páginas
- manutenção interna da B-Tree
E no SQL Server Standard o problema fica ainda pior por causa do rebuild offline e dos locks gerados.
Então a pergunta moderna não é:
“meu índice está fragmentado?”
A pergunta correta é:
“essa fragmentação realmente está causando impacto no meu workload?”
Quer entrar na carreira de dados ou desenvolver suas capacidades como DBA, Analista de Dados, Analista de Infra ou DEV?
Segue as minhas principais formações:
- Coloque comentário que gostaria de ter acesso aos cursos com desconto.
- AcademiaDBA. Formação Completa para DBA.
Aprenda SQL Server, Oracle, PostgreSQL, MySQL, Data Warehouse, ETL com SSIS/SSAS e Power BI em uma plataforma prática e focada na carreira, criada para ajudar você a se tornar um profissional confiante em banco de dados e dados.
1316 aulas e 412 horas de conteúdo original
Legendas: Portugues
https://formacaodba.academiadba.com/
1.1 DBAcademy. Master Databases.Build a Real Data Career.
Learn SQL Server, Oracle, PostgreSQL, MySQL, Data Warehousing, ETL with SSIS/SSAS, and Power BI in one practical, career-focused platform designed to help you become a confident database and data professional.
1316 class e 412 hours
Subtitles: English, Spain, France
https://dbacademy.academiadba.com/
- Mastering SQL Server – 86 horas: torne-se um DBA SQL Server
Curso Completo de DBA SQL Server: Aprenda do Zero, na Prática, com Azure, Performance, Segurança e Alta Disponibilidade.
https://www.udemy.com/course/servino_sqlserver/
2.1 Dominando scripts PowerShell para o SQL Server
Do básico ao avançado: aprenda PowerShell passo a passo e transforme sua rotina de DBA com automações inteligentes.
https://www.udemy.com/course/dbapowershell/
2.2 Toolkit do DBA SQL Server
Monitoramento com DBADASH, Stress Test com SQLQUERYSTRESS, DBATools e Scripts Essenciais para o DBA SQL Server
https://www.udemy.com/course/toolkitdbasqlserver/
2.3 SQL Server DBA Toolkit
Monitoring with DBADASH, Stress Testing with SQLQUERYSTRESS, DBATools, and Essential Scripts for the SQL Server DBA. In English
https://www.udemy.com/course/sql-server-dba-toolkit/
2.4 Cluster-AG Always ON e Log Shipping no SQL SERVER 2025
Aprenda a configurar ambiente de disaster recovery no SQL Server usando o Cluster com AG Always on e Log Shipping
https://www.udemy.com/course/logshippingsqlserver/
- Curso Postgres Completo, 50 horas – Formação DBA
Aprenda Banco de Dados Postgres, Modelagem de Dados e programação usando SQL – do básico ao avançado
https://www.udemy.com/course/postgrescompleto/
3.1 Cluster Postgres: Domine Clusters Gerenciado pelo Patroni
Aprenda a montar um cluster PostgreSQL robusto no Linux utilizando Patroni, ETCD, HAProxy e Keepalived
https://www.udemy.com/course/clusterpostgres/
3.2 Postgres Cluster: Master Patroni-Managed Clusters
Learn how to build a robust PostgreSQL cluster on Linux using Patroni, ETCD, HAProxy and Keepalived. In English
https://www.udemy.com/course/postgres-cluster/
- Curso ORACLE Completo – 89 horas, formação DBA
Aprenda Banco de Dados Oracle, Modelagem de Dados e programação usando PL/SQL – do básico ao avançado
https://www.udemy.com/course/dbaoracle/ - Curso MySQL Completo – 123 horas, formação DBA
Aprenda MySQL, SQL, Azure MySQL, Modelagem de Dados, Windows Server e Linux Ubuntu Server – do básico ao avançado
https://www.udemy.com/course/mysqlcompleto/
5.1 MySQL Course – 75 Hours, Become a DBA
MySQL Course – 75 hours, DBA training. Learn MySQL / SQL Language – From Basic to Advanced. In English
https://www.udemy.com/course/mysqlcourse/
- Curso Analista de Dados, formação profissional – 52 horas
Aprenda SQL Server, modelagem de dados, Linguagem SQL, SSIS, SSAS, data Warehouse, Stage, Power BI
https://www.udemy.com/course/analistadados/ - Curso PowerBI – Formação Analista de BI – 28 horas
PowerBI, Linguagem SQL e Modelagem de Dados, do básico ao avançado. Se torne um Analista de BI – Business Intelligence
https://www.udemy.com/course/curso-powerbi-completo/ - Guia Completo para a Carreira de DBA
Como conquistar sua primeira vaga como DBA — mesmo começando do zero e evoluir até pleno ou criar seu próprio negócio
https://www.udemy.com/course/guiacarreiradba/ - Analista de Dados: Da Primeira Vaga ao Negócio Próprio
Aprenda a se posicionar, conseguir entrevistas, passar em processos seletivos, trabalhar bem nos primeiros 90 dias
https://www.udemy.com/course/guianalistadados/
Bons Estudos
Prof. Msc Sandro Servino
www.academiadba.com
Share this content:
Post Comment