Índices

Índices são estruturas que possuem algoritmos otimizados para acessar dados em um banco de dados. Tais estruturas constituem uma ferramenta poderosa para o projetista do Banco de Dados no intuito de auxiliá-lo na melhora do desempenho das consultas.

O principal papel de um índice é reduzir o número de operações de I/O (leitura e escrita) necessários para localizar os dados solicitados por uma consulta. Sendo assim, ao fazer uso dos índices, o SQL Server 2005 rapidamente localizará e disponibilizará os dados de uma consulta através de um número de I/O muito menor. Ao não utilizar índices, o SQL Server precisa realizar uma operação conhecida como Table Scan, para localizar os dados solicitados. Uma operação Table Scan é uma leitura seqüencial de todos os registros da tabela, o que implica muito mais operações de I/O no disco. As operações de I/O em disco são normalmente bastante lentas quando comparadas com operações de leitura e escrita em memória.

Os índices podem ser criados em qualquer coluna da tabela, inclusive em uma coluna com valores calculados. O corpo de um índice é formado pelas colunas de uma tabela cujos dados se deseja classificar seguido de uma referencia conhecida como “ponteiro”, que serve para localizar a página de dados da tabela (BATTISTI, 2005).

Index Clustered

Um clustered index armazena os dados ordenados de acordo com os valores do campo onde o índice foi definido. Ao definir um clustered index, o mesmo organiza os dados da página de acordo com sua chave. Neste caso, o índice está alterando a ordem aleatória da tabela. Este tipo de índice é bastante rápido eficiente para agilizar as operações de localização de registros. Somente podemos ter um clustered index por tabela, pois só poderemos armazenar os dados em ordem de um determinado critério.

Embora o índice melhore o desempenho das consultas, existe um pequeno “overhead” para operações de atualização, inserção e exclusão de registro, pois estas operações podem fazer com que a ordem dos registros seja alterada, e que estes tenham que ser reposicionados para manter a ordem definida pelo índice.

Non-Clutered Index

Ao se criar um índice não-cluster cria-se na verdade uma estrutura que, através de ponteiros, ligará a linha do índice à correspondente página da tabela sem alterar sua ordem. Os registros estarão armazenados em uma ordem aleatória, porém poderão ser facilmente localizados através do ponteiro.

A utilização desse tipo de índice é indicada quando os dados podem ser pesquisados por diferentes critérios, uma vez que podemos criar vários nonclustered index em uma tabela.

Uma novidade do SQL Server 2005 é a possibilidade de ampliar a funcionalidade de um nonclustered index, através de colunas que não são chaves, como parte do último nível ou camada de nós da folha de dados. Esta opção poderá melhorar consideravelmente o desempenho das consultas.

O SQL Server 2005 usa a chave clusterizada na página de índice para colocar o ponto do índice, e uma chave armazenando o local da informação. Tabelas que contém índices cluster e índices não cluster são muito comuns. O melhor nessas situações é criar o índice cluster primeiro (que irá organizar os dados e o índice em ordem ascendente) e depois criar o índice não clusterizado nas colunas que forem necessárias como FK`s, ou colunas muito acessadas. Deve-se tomar cuidado com a utilização dos dois tipos de índices em uma única tabela. Nesse caso o SQL acaba por utilizar os dois meios de busca gerando um I/O muito grande.

Index Keys

Index Keys são as colunas utilizadas para a definição de um índice. A chave do índice é um valor que permite que o registro correspondente seja facilmente localizado. Nesse caso o valor a ser procurado será exatamente igual ao valor da chave.

Index Uniqueness

Nesse tipo de índice não há unicidade nos valores armazenados. Um índice não único permite valores repetidos para a chave, porém será proporcionalmente mais efetivo quanto mais variarem os valores para o campo.

FILL FACTOR

A opção fill factor determina qual a porcentagem de uma página de dados deve ser preenchido com o índice e quanto deve ser mantido em branco, reservado para inclusões e alterações. Por exemplo, se utilizarmos o fill factor igual a 80%, então o SQL Server irá apenas preencher 80% de cada página com os índices. Se alterarmos ou incluirmos dados, o SQL consegue reorganizar os índices de uma maneira mais rápida, pois ele tem 20% de espaço em branco em cada página de dados para poder preencher.

A decisão de usar ou não fill factor depende do número de inclusões e alterações que se espera receber em uma tabela. Se o banco for utilizado somente para consulta, então a melhor coisa a se fazer é colocar o fill factor 100%, pois não há necessidade de deixar espaço em branco nas páginas de índices, já que eles jamais serão reorganizados.

Imagine que uma tabela tem 1.000.000 de registros e que, diariamente, 10.000 novos registros são adicionados ou modificados. Se colocado o fill factor igual a 90%, muito provavelmente em dez dias o espaço em branco que o SQL Server reservou já foi tomado. Nesse contexto haverá uma queda de desempenho na hora de incluir registros na tabela. Agora, se colocado o fill factor igual a 70%, não teremos queda de performance durante um mês.

Quanto maior o fill factor maior será o tempo entre manutenções do índice do banco de dados.

O fill factor ideal de um índice será aquele que causar menos fragmentação para um determinado período de analise

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s