TECNOLIGIA

BEIGHLEY, Lynn. Use a cabeça SQL. Rio de Janeiro: Alta Books, 2008

Embora o uso de índices seja uma função básica para todos os principais SGBDs e ferramenta fundamental para a qualidade das consultas em banco de dados, é muito comum que desenvolvedores negligenciem seu uso. Um dos motivos é que normalmente as consultas SQL são confeccionadas durante o desenvolvimento dos sistemas, quando as tabelas possuem poucos registros. À medida que elas crescem em tamanho, problemas de desempenho começam a aparecer.

Para entender o motivo, vou fazer uma analogia. Imagine que você esteja na escola assistindo uma aula de história e a sua professora peça para abrir o livro na página 12. O que você faz? Molezinha. Você, que já sabe desde cedo que todo livro possui numeração nas páginas, o abre logo no início e folheia um pouco até a página desejada.

E se a professora pedisse para que procurasse alguma página que faça referência ao ex-presidente Getúlio Vargas? Sabendo que normalmente estes livros possuem índices remissivos no final, você então procura neste índice pelo nome “Getúlio Vargas”, olha em que página ele se encontra e folheia até ela. Um pouco mais trabalhoso, porém sem grandes dificuldades.

Agora, e se por alguma falha da editora o seu livro não possuísse este último índice? Como você faria para achar alguma referência a Getúlio Vargas? Provavelmente você teria que ler o livro inteiro. Trabalhoso, não? Pois é, isso é exatamente o que um SGBD precisa fazer quando efetuamos uma consulta SQL que não faz uso de nenhum índice. Ele precisa varrer a tabela inteira. Sem muitos problemas em tabelas pouco copuladas (ou quando você realmente deseja retornar todos os registros), mas em tabelas com milhares, milhões ou até bilhões de registros isso se torna um problema.

É importante perceber que, mesmo quando aplicamos um filtro em uma consulta e esta retorna um número reduzido de registros, não necessariamente será uma consulta eficiente.

Esta é a função dos índices no SQL Server e em outros SGBDs. Achar os registros com mais eficiência. Pode ser um SELECT, UPDATE ou DELETE, o SQL Server vai sempre tentar achar a forma mais rápida de executar uma QUERY.

O índice clusterizado, quando presente, é nada mais nada menos que a tabela em si, ordenada por uma ou mais colunas. Uma tabela só pode ter um (1) índice clusterizado.

Um índice clusterizado é criado automaticamente quando se é definida uma contraente do tipo PRIMARY KEY para uma ou mais colunas. Quando este índice é criado em uma (ou mais) coluna(s) que não garanta(m) sua unicidade, será criado internamente um identificador único, chamado “uniqueifier”. Este índice é muito importante, pois ele quando usado em conjunto com o índice não clusterizado (explicado em seguida), torna a consulta mais eficiente.

Nesta consulta, o SQL efetua a busca usando diretamente o índice clusterizado, pois o filtro é aplicado na chave primária da tabela, que está ordenada. A prova está no plano de execução abaixo (para ativá-lo pressione CTRL+M e rode a consulta). Note o uso do operador “Seek” (busca).

Perceba a semelhança desta consulta com o primeiro exemplo do livro de história. É como se estivéssemos buscando diretamente no número da página, o que é muito eficiente.

Um índice não clusterizado é análogo ao índice remissivo do livro no nosso exemplo acima. Procuramos pelo nome “Getúlio Vargas” no índice (em ordem alfabética), que possui o número da página em que ele é referenciado. Temos apenas o trabalho de memorizar o número e folhear até a página.

No SQL, quando criamos um índice não clusterizado, usamos uma ou mais colunas como chave. O SQL Server então ordena estas colunas e cria um ponteiro para o registro na tabela. Isso significa que os índices e seus registros são criados fisicamente no bando de dados.

Vamos à pratica. Considere a consulta abaixo:

1

2

3

4

5

6

7

8 use AdventureWorks

select

UnitPrice

, OrderQty

from

Sales.SalesOrderDetail sod

where

CarrierTrackingNumber='4ECF-42F2-A7'

Mesmo tendo retornado somente 10 registros em um universo de centenas de milhares, o SQL Server precisou escanear a tabela inteira para nos retornar os pedidos com o filtro CarrierTrackingNumber=’4ECF-42F2-A7′, pois não temos nenhum índice definido nesta coluna (lembra do terceiro exemplo do nosso livro de história?). Comprovamos isso pelo uso do operador “Scan” (escaneamento) aplicado na tabela, nada eficiente para uma tabela com muitos registros.