Fim do Table Scan
Acabei de terminar uma série de artigos falando sobre Table Scan e agora vou dizer que não existe futuro para o Table Scan (IAM Scan).
- 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
O motivo de dizer isso é apresentar a Regra Ninja de Performance #2:
A regra é bem simples: se você quer desempenho, então precisa organizar o recurso da forma adequada. Em um banco de dados transacional (OLTP), todas as consultas devem ser feitas através de índice. Não faz sentido acessar os dados através de Table Scan. Em ambiente de Data Warehousing e OLAP, as informações devem ser guardadas em um formato Columnar, que são obtidos usando os índices ColumnStore.
Claro que existem exceções, como por exemplo, tabelas temporárias ou staging podem economizar tempo de processamento usando Heaps simples.
Por que nunca alguém me disse isso antes? (Ou pelo menos, não com essas palavras)
Meu palpite: os índices ColumnStore se tornaram viáveis a partir do SQL 2016, quando é possível realizar operações DML e criar índices BTree sobre as tabelas com índices ColumnStore.
Fim do Table Scan
O correto seria dizer o fim do IAM Scan. No próximo artigo, vou mostrar que o BTree Scan (Index Scan) ainda continua vivo por conta da estratégia de Covering Index.