A ausência de índices em tabelas com muita leitura
causa a degradação do banco pela demora de retorno de resultados, crescimento
excessivo do banco tempdb e concorrência junto de outros processos que também
esperam retorno de outras consultas. A criação excessiva de índices em tabelas
também é muito prejudicial, principalmente se ela recebe muitos inserts e
updates. O índice nada mais é do que uma minitabela que organiza os registros
de uma tabela a fim de dar um retorno rápido a uma consulta emitida. Nesta
matéria você irá aprender quando criar índices, o que é a fragmentação, e as
melhores práticas para se trabalhar com este objeto que agiliza muito uma
consulta, desde que se saiba aplicar de forma correta.
Índices, em qualquer plataforma de banco de dados, têm por objetivo agilizar uma consulta na busca de registros em uma tabela ou view. Eles não são eficazes para buscar uma imensidão de registros dentro de uma tabela, a busca por registros em uma consulta deve ser a mais seletiva possível a fim de que seja retornado menos que 10% do total de informações de uma tabela, caso contrário seu índice não terá eficiência e ainda irá prejudicar o banco em operações de insert e update.
Os índices contêm chaves criadas de uma ou mais colunas de tabelas ou views e estas chaves são armazenadas em uma estrutura de árvore também conhecida como B-Tree.
Este tipo de estrutura habilita o SQL Server a localizar linhas associadas aos valores de chave de forma rápida e eficaz. Existem dois tipos de índices no SQL Server, e se dividem entre:
· Clusterizados;
· Não clusterizados.
Ambos podem ser compostos ou únicos. Um índice composto é aquele que contém mais de uma coluna. No SQL Server 2005 e 2008 você pode incluir até 16 colunas em um índice enquanto ele não exceder o limite de 900 bytes de tamanho.
A partir da versão 2012 estes valores foram expandidos para 32 colunas e o limite de tamanho foi expandido para 1.700 bytes.
O índice único é exclusivo e garante a singularidade de cada valor na coluna indexada. Se o índice é um composto, a exclusividade é aplicada através das colunas como um todo, não em colunas individuais. Por exemplo, se você fosse criar um índice nas colunas FirstName e LastName em uma tabela, juntos os nomes devem ser exclusivos, mas os nomes individuais podem ser duplicados.
Diferença entre índices clusterizados e não clusterizados
Índices clusterizados são criados automaticamente quando se define uma chave primária para um ou vários campos em uma tabela. Desta forma é mantida uma exclusividade de dados. Os índices também são criados de forma explícita quando o DBA executa a instrução Create Index indicando os campos que farão parte deste objeto. Só pode existir um índice clusterizado por tabela.
Em um índice clusterizado, os registros em uma tabela são fisicamente ordenados dentro da tabela. Já um índice não clusterizado, ao ser criado, não possui uma ordenação física, pois sua construção é feita no heap.
Heap é o nome que se dá a tabelas que não possuem índices clusterizados. Os dados destas tabelas não possuem uma ordem lógica e são gravados nas páginas que possuem espaço disponível. O índice não clusterizado é aconselhável para colunas que possuem baixa cardinalidade, ou seja, não possuem uma variação grande de valores. Ao contrário dos índices clusterizados, podemos ter mais de um índice não clusterizado em uma tabela.
Em função das diferenças entre índices clusterizados e não clusterizados, suas arquiteturas também diferem, conforme demonstram as Figuras 1 e 2. Representado na Figura 1, no índice clusterizado as páginas da cadeia de dados e as linhas são classificadas pelo valor da chave de índice.
Todas as inserções são feitas no ponto em que o valor de chave da linha inserida se ajusta à sequência de classificação entre as linhas existentes.
Representado na Figura 2 temos o índice não clusterizado. Note que as linhas de dados da tabela subjacente não são classificadas nem armazenadas em ordem com base nas suas chaves não clusterizadas.
Além disso, a camada de folha de um ...
