Os índices de banco de dados são usados para acelerar diferentes operações de tabela. No entanto, antes de criar um índice, é importante saber se você realmente precisa de um índice? E se você precisar criar um índice, quais são os pontos importantes que devem ser lembrados? É aqui que entra o design de índice de banco de dados.
Este artigo tem como objetivo responder a essas perguntas sobre o design de índice de banco de dados e esclarecer algumas das principais considerações que um desenvolvedor de banco de dados deve levar em consideração ao projetar um índice.
1. Tamanho da tabela
A primeira pergunta que um desenvolvedor de banco de dados deve fazer antes de criar um índice é se a tabela é grande o suficiente para usar índices com eficiência. Se o tamanho da tabela for pequeno, o mecanismo do SQL Server poderá verificar a tabela completa mais rapidamente do que pesquisar a tabela por meio de um índice. Índices nesse caso não têm utilidade e criam uma sobrecarga durante a execução de operações de banco de dados.
2. Tipos de coluna
Os índices devem ser criados em uma coluna de chave primária ou em qualquer coluna que contenha valores exclusivos e que tenha uma restrição NOT NULL. Além disso, é aconselhável criar índices em colunas numéricas, pois colunas numéricas tendem a ter mais valores exclusivos em comparação com colunas não numéricas. Um design de índice de banco de dados ruim usa índices em colunas que têm poucas entradas exclusivas e podem resultar em consultas muito demoradas.
Considere uma tabela chamada Pacientes que contém centenas de milhares de registros. A tabela Pacientes conteria uma coluna chamada “Gender” que pode ter apenas dois valores únicos “Masculino” e “Feminino”. Se você criar um índice na “Coluna Gênero”, os registros serão classificados em ordem alfabética crescente ou decrescente.
Portanto, se você tiver um milhão de registros na tabela Pacientes e o número de pacientes do sexo masculino e feminino for igual, no índice o primeiro meio milhão de registros terá o gênero “Feminino” e o segundo meio milhão terá o gênero “Masculino”. Agora, se você quiser procurar uma mulher que exista na linha 490.000 dos registros femininos, o SQL Server Engine terá que verificar 490.000 registros. Por outro lado, com valores numéricos exclusivos, a pesquisa pode ser extremamente rápida, pois os índices do SQL Server são armazenados na forma de B + Trees e, portanto, os valores numéricos nos nós da árvore podem acelerar as operações do banco de dados.
3. Número de índices
Oficialmente, você pode criar um índice clusterizado e quantos índices não clusterizados desejar para cada tabela do banco de dados. No entanto, é um bom design de índice de banco de dados criar um índice clusterizado e apenas um número limitado de índices não clusterizados absolutamente necessários. A criação de muitos índices não clusterizados pode realmente retardar as operações de atualização e inserção porque quando um registro é atualizado ou inserido e um valor de coluna é alterado, todos os índices associados precisam ser atualizados.
Considere um cenário em que temos dois índices não agrupados, o primeiro índice classifica os registros por idade e o segundo índice classifica os registros por sexo e idade.
Aqui está o primeiro índice:
| Idade | Registro de endereço |
| 10 | Endereço de registro |
| 22 | Endereço de registro |
| 29 | Endereço de registro |
| 32 | Endereço de registro |
| 33 | Endereço de registro |
| 36 | Endereço de registro |
| 40 | Endereço de registro |
| 49 | Endereço de registro |
| 54 | Endereço de registro |
| 59 | Endereço de registro |
E aqui está o segundo:
| Gender | Idade | Registro de endereço |
| Feminino | 10 | Endereço de registro |
| Feminino | 29 | Endereço de registro |
| Feminino | 33 | Endereço de registro |
| Feminino | 40 | Endereço de registro |
| Feminino | 54 | Endereço de registro |
| Masculino | 22 | Endereço de registro |
| Masculino | 32 | Endereço de registro |
| Masculino | 36 | Endereço de registro |
| Masculino | 49 | Endereço de registro |
| Masculino | 59 | Endereço de registro |
Agora, se um registro com 40 anos de idade tiver que ser atualizado para 15 anos por algum motivo, o primeiro índice terá que ser atualizado para mover o registro da 7ª posição (40) para a segunda posição para manter o índice classificado. Da mesma forma no segundo índice, o registro no 4º índice será movido para o segundo índice. Muita reorganização tem que acontecer. Portanto, é aconselhável manter o número de índices no mínimo para as colunas que são atualizadas regularmente ao pensar no design do índice do banco de dados. Além disso, uma coluna não deve ser usada em vários índices não clusterizados.
4. Local de armazenamento de índices
O local de armazenamento de um índice pode afetar o desempenho das consultas que usam o índice e, portanto, também faz parte de um bom design de índice de banco de dados. Por padrão, um índice clusterizado é armazenado no mesmo grupo de arquivos da tabela na qual o índice é criado. Para índices não clusterizados, o índice pode ser armazenado no mesmo grupo de arquivos ou em grupos de arquivos diferentes abrangendo várias unidades de disco. O desempenho da consulta de índices não clusterizados pode ser significativamente aprimorado armazenando índices não clusterizados em várias unidades de disco. Isso ocorre porque o desempenho de entrada/saída da consulta será aprimorado como resultado da distribuição dos dados em diferentes áreas da unidade.
O local de armazenamento padrão dos índices também pode ser alterado especificando um valor para a opção FILLFACTOR. Como os índices são armazenados fisicamente na forma de Árvores B+, os dados do índice são armazenados em páginas folha. Com a opção FILLFACTOR, você pode definir a porcentagem das páginas em nível de folha a serem preenchidas. Por exemplo, se você definir o valor de FILLFACTOR para 70%, apenas 70% do espaço total da página em nível de folha será preenchido por dados de índice. Os 30% restantes serão deixados para o crescimento automático dos dados do índice no futuro.
5. Tipos de índice
Outra consideração extremamente importante no projeto de índice de banco de dados é o tipo de índice a ser usado. Em um artigo anterior (adicione um link para o artigo “Quando usar índice clusterizado ou não clusterizado”), expliquei a diferença entre índices clusterizados e não clusterizados. Também expliquei o que são e como podem ser usados. A decisão de escolher um índice clusterizado ou não clusterizado é crucial e deve ser cuidadosamente pensada.
Os pontos a seguir devem ser mantidos em mente ao decidir qual tipo de índice escolher.
- Para as colunas usadas em consultas SELECT/JOIN/GROUP BY/BETWEEN, use índices clusterizados.
- Use índices não clusterizados para colunas em que você deseja recuperar apenas valores dessa coluna específica e não de outras colunas da mesma linha. Consultas SELECT que recuperam vários registros usando um índice não clusterizado podem ser lentas porque o mecanismo do SQL Server primeiro pesquisa os valores de coluna nos quais o índice é criado e, em seguida, usando a referência de linha para o valor da coluna, os registros das tabelas de banco de dados reais são recuperados .
- Para as colunas que geralmente passam por operações INSERT e UPDATE, use um índice não clusterizado. Certifique-se de não usar uma coluna em vários índices não clusterizados, pois isso pode retardar as consultas de atualização. Índices clusterizados podem ser lentos para operações INSERT/UPDATE porque a linha completa precisa ser atualizada em vez de apenas um valor de coluna única, como é o caso de índices não clusterizados.
- Como você só pode criar um índice clusterizado, no caso de precisar de vários índices, use índices não clusterizados. No entanto, se o espaço em disco for uma grande preocupação, mantenha o número de índices não agrupados no mínimo.
Outras Considerações
Embora essas sejam as cinco partes mais importantes do design do índice de banco de dados, elas não são tudo. É importante especificar a ordem correta das colunas nos índices. Como regra geral, as colunas que são usadas para tomada de decisão em cláusulas WHERE e condições como maior que (>), menor que (<) etc, devem ser colocadas antes das colunas não envolvidas nessas cláusulas. No caso de várias colunas na cláusula WHERE, os nomes de coluna mais distintos devem ser mencionados primeiro na definição do Índice.
Além do design do índice do banco de dados, o design da consulta também desempenha um papel importante no uso eficiente do design do índice. Para uma manutenção de índice otimizada em vez de gravar várias consultas que operam em um pequeno número de linhas, tente gravar menos consultas que afetem um número maior de linhas da tabela.
Conclusão
Este artigo explica algumas das principais considerações que um desenvolvedor de banco de dados deve levar em consideração ao analisar o design de índice de banco de dados. O artigo também explica a lógica por trás dessas considerações e contém outras sugestões para garantir que o design do índice do banco de dados seja eficiente.
