Aprendi SQL com comandos obsoletos

Foram 10 artigos escritos sobre a “Saga da otimização com comandos antigos”, na qual usei o objetivo era mostrar alguns conceitos importantes do SQL Server.

• Parte 1: SET STATISTICS IO
• Parte 2: DBCC DROPCLEANBUFFERS
• Parte 3: DBCC SHOWCONTIG
• Parte 4: DBCC PAGE
• Parte 5: sp_spaceused
• Parte 6: DBCC IND
• Parte 7: DBCC INDEXDEFRAG
• Parte 8: DBCC DBREINDEX
• Parte 9: sp_detach_db
• Parte 10: SET SHOWPLAN_TEXT

Assim aprendi como funciona um banco de dados:

1. O importante é sempre medir I/O
2. Existem duas estruturas de dados importantes: Heaps e B-Trees
3. Fragmentação de dados impacta diretamente o desempenho do Table Scan

Table Scan

Embora muita gente (eu inclusive!) diga que Table Scan e Desempenho não combinam, precisamos compreender a importância do Table Scan em um banco de dados relacional. Essa é a operação mais eficiente para ler um grande número de registros, sendo superior a qualquer forma de Index Seek/Row Lookup. Por isso, o Table Scan é uma operação presente em grandes Data Warehousing e não podemos ignorá-la.

Como principal fundamento do Table Scan, o Read-Ahead (também chamado de read prefetch) é usado para consolidar múltiplas solicitações de I/O em apenas uma requisição. A diferença em desempenho é brutal e pode melhorar em 10x.

O principal inimigo do Table Scan é a fragmentação dos dados em disco, que impede o SQL de realizar read-aheads. Isso pode se manifestar em estruturas do tipo Heap ou B-Tree.

Relendo os Artigos

Quando pensei em escrever os artigos sobre desempenho de banco de dados, achei que seria importante ressaltar o conceito de IAM Scan. O motivo é simples: há pouca documentação sobre essa operação. Decidi escrever os artigos usando um tema sarcástico: “otimização com comandos antigos” e, agora que conclui, acabei me arrependendo por não conseguir dar o foco correto à série.

Por isso, recomendo que entendam que cada artigos possui uma motivação por trás:

• A importância de medir I/O e o cuidado com o Cache em memória
  • Parte 1: SET STATISTICS IO
  • Parte 2: DBCC DROPCLEANBUFFERS
• Estrutura Heap e sua fragmentação
  • Parte 3: DBCC SHOWCONTIG
  • Parte 4: DBCC PAGE
  • Parte 5: sp_spaceused
• Estrutura B-Tree e sua fragmentação
  • Parte 6: DBCC IND
  • Parte 7: DBCC INDEXDEFRAG
  • Parte 8: DBCC DBREINDEX
• Impacto da fragmentação
  • Parte 9: sp_detach_db
• Por que Table Scan quando um índice resolve?
  • Parte 10: SET SHOWPLAN_TEXT

Meu artigo favorito é a Parte 5: sp_spaceused, na qual fica explícito um comportamento indesejado das Heaps.

Todos os artigos tentam mostrar os problemas que impactam diretamente o desempenho o Table Scan.

O último artigo (Parte 10: SET SHOWPLAN_TEXT) mostra que, quando se retornam POUCOS registros, então um índice funciona melhor. No próximo artigo, gostaria de discutir mais e falar sobre o "fim do table scan".

Comments

• Anonymous
  June 01, 2016
  Como sempre sendo o grande diferenciador do mundo SQL Server, obrigado por dedicar seu tempo para escrever artigos valiosos como esse.
  • Anonymous
    June 01, 2016
    Obrigado Luan! É muito bom receber um feedback seu.