Antes de começar a escrever suas buscas pelos dados , recomendo você a primeiro ter uma ideia do que é mais importante para seus usuários.
Quais valores e o tamanho de seus subconjunto vão conduzir a escolha do(s) índice(s) . O índice nada mais é que uma forma de acessar
mais rapidamente uma informação específica. Aqui é muito importante perceber que “informação específica” não é “todas as informações”.
E apesar de contribuirem para o acesso a determinados dados, eles vêm com um custo, tanto em armazenamento quanto em processamento. Por isso
a estratégia adotada na criação de um indice deve considerar, por exemplo, que o volume de armazenamento de um indice pode ser muito maior
que o volume de armazenamento do dado que está sendo indexado. Considere os índices em suas estratégias de backup/restore.
E quanto ao processamento? Toda ação de insert/delete/update no banco, refletirá em ajustes nos indices da tabela. E estes, ajustes se aplicam
não só nos indices simples ( que referenciam apenas a coluna alterada) mas também aos indices compostos (compound index) , toda esta alteração ( ou manutenção)
reflete em mais recursos de CPU sendo usados para varrer dados em memória, I/O porque essas atividades consomem log e ainda alguma manutencao de armazenamento
nos arquivos de banco.
A seguir algumas estrategias que podem ajudar na escolha dos seus índices:
– Conhecer as características da base : Se ocorrem muitas modificações no banco de dados ( OLTP ) ou se é um sistema de apoio a decisão (DSS) ou Data
Warehousing (possui normalmente dados apenas de leitura e em grande volume ).
– Conhecer as características das consultas mais executadas : se usam muitos “joins” ou funções para validar dados.
– Identificar as colunas mais utilizadas como filtros,, bem como suas caracteristicas ( o idel sao colunas que nao permitem valores nulos, que possuam valores unicos e que sejam do tipo inteiro)
– Determinar o tipo de indice que pode ser criado ( em geral varia com o sistema de banco de dados usados, mas a grande maioria possui “clustered index” e “nonclustered index”)
– Determinar o armazenamento do indice. De preferencia num grupo de arquivos separados dos dados .
Existem ainda algumas considerações quanto ao Base de Dados :
– Quanto maior a quantidade de indices em uma tabela mais a perfomance em INSERT, UPDATE, DELETE é afetada , porque todos os indices devem ser ajustados de acordo com as alterações nos dados.
– Se possível manter a combinacao de indices com um numero pequeno de colunas .
– Algumas vezes considerar o tempo que otimizador de consulta usa para varrer indices em tabelas pequenas, as vezes, é menos custoso varrer diretamente a tabela de dados e mais, podem ainda nunca
serem usados, apenas consumindo espaco .
– indices em views podem ser uteis quando a view contem agregações, joins ou ambos. ( Depende do Sistema de Banco de dados)
E com relação as consultas :
– Verificar a ordem de uso das colunas indexadas, especialmente as que participam de indices compostos. A coluna usada no WHERE em igual a (=), maior que (>), menor que (<), ou BETWEEN, ou se participar um join , deve ser usada primeiro. Colunas adicionais devem ser ordenadas
com base em seu nível de distinção, ou seja, do mais distinto ao menos distinto.
Por exemplo, se o índice for definido como a, b o índice será útil quando a busca for WHERE a = ‘xxx’ ou WHERE b =’zzzz’ AND a LIKE ‘x%’.
Se a consulta que tivesse pesquisado apenas em b (WHERE b = ‘Jane’), o otimizador de consulta não usaria o índice.
– Prefira consultas que insiram ou modifiquem o máximo de registros possíveis em uma única instrução,
em vez de usar consultas múltiplas para atualizar esses mesmos registros. Ao usar apenas uma instrução, ocorre manutenção otimizada do índice, evitando maior fragmentacao.
