Qual a melhoria que os índices podem fazer no sql server?
11/08/2017
0
Galera, tenho uma dúvida essa questão. Os índices de fato melhoram o desempenho de consulta no banco de dados? E se eles de fato trazem uma melhora significativa, não há nenhuma "perda" em usá-los, digo uma desvatangem?
Carlos Arantes
Curtir tópico
+ 0
Responder
Post mais votado
12/08/2017
Carlos, existe sim vantagem e desvantagem na utilização de índices, e isso em qualquer banco de dados relacional, não apenas SQLServer.
Quando utilizamos índices, o banco de dados cria como se fossem índices hash (eu lembro de ter estudado isso na faculdade, mas o termo exato do que ele cria eu não me recordo), de modo que quando faz uma busca ele já sabe aonde está determinado valor.
Vamos a um exemplo: Considere o array 12345. Ao buscar o 4, no caso de não utilizar índice o banco de dados fará uma busca sequencial no array, passando pelo 123 desnecessariamente. Já com a utilização dos índices o banco utiliza uma formulas para armazenar índices únicos para certos dados e conjuntos de dados. Supondo por exemplo que esteja utilizando índice na mesma busca acima, ao buscar o 4 ele aplicaria f(X), sendo x =4 (f(4)), tal que o resultado da função já é o endereço de memória onde se encontra o 4, e que na maioria dos casos a aplicação do índice executando a formula do mesmo ( f(x) ) é muito mais barato do que percorrer o array.
Porém, não são tudo flores. Para saber onde está o endereço de memória de 4 primeiramente o banco de dados, ao armazenar o 4 no banco de dados, faz o f(4) e armazena seu resultado e aonde estão os endereços de memória que ele está gravado e os armazena em tabelas hash de consulta.
Resumindo, há muita vantagem de utilizar-se índice para consultas porém há perda durante o armazenamento destes dados. Na maioria dos casos é muito vantajoso a utilização de índices, tendo em vista que teremos poucos usuários (abaixo de 100 mil) acessando e alimentando nossas bases de dados, porém é até comum empresas grandes não trabalharem com bancos de dados relacionais totalmente amarrados (utilizando índices ou todas as firulas de bancos ER) pois assim ganham nanosegundos nos tempos de gravação e salvam alguns milhares de dinheiros.
Porém, não é recomendada esta última prática citada, para tal existem os NOSql (Not Only SQL).
Espero ter ajudado.
Quando utilizamos índices, o banco de dados cria como se fossem índices hash (eu lembro de ter estudado isso na faculdade, mas o termo exato do que ele cria eu não me recordo), de modo que quando faz uma busca ele já sabe aonde está determinado valor.
Vamos a um exemplo: Considere o array 12345. Ao buscar o 4, no caso de não utilizar índice o banco de dados fará uma busca sequencial no array, passando pelo 123 desnecessariamente. Já com a utilização dos índices o banco utiliza uma formulas para armazenar índices únicos para certos dados e conjuntos de dados. Supondo por exemplo que esteja utilizando índice na mesma busca acima, ao buscar o 4 ele aplicaria f(X), sendo x =4 (f(4)), tal que o resultado da função já é o endereço de memória onde se encontra o 4, e que na maioria dos casos a aplicação do índice executando a formula do mesmo ( f(x) ) é muito mais barato do que percorrer o array.
Porém, não são tudo flores. Para saber onde está o endereço de memória de 4 primeiramente o banco de dados, ao armazenar o 4 no banco de dados, faz o f(4) e armazena seu resultado e aonde estão os endereços de memória que ele está gravado e os armazena em tabelas hash de consulta.
Resumindo, há muita vantagem de utilizar-se índice para consultas porém há perda durante o armazenamento destes dados. Na maioria dos casos é muito vantajoso a utilização de índices, tendo em vista que teremos poucos usuários (abaixo de 100 mil) acessando e alimentando nossas bases de dados, porém é até comum empresas grandes não trabalharem com bancos de dados relacionais totalmente amarrados (utilizando índices ou todas as firulas de bancos ER) pois assim ganham nanosegundos nos tempos de gravação e salvam alguns milhares de dinheiros.
Porém, não é recomendada esta última prática citada, para tal existem os NOSql (Not Only SQL).
Espero ter ajudado.
Ermesom Lourenco
Responder
Mais Posts
14/08/2017
Carlos Arantes
Bom dia Ermesoml,
Cara muito obrigado pela resposta tão detalhada! Parece que a perda nesse caso não se compara ao ganho, porque parece que a performance do desempenho da consulta pode alcançar um nível bem satisfatório pelo visto.
Vou começar a implementar o uso de índices nas minhas consultas para ver na real como isso vai funcionar!
Muito obrigado pela ajuda amigo!
Cara muito obrigado pela resposta tão detalhada! Parece que a perda nesse caso não se compara ao ganho, porque parece que a performance do desempenho da consulta pode alcançar um nível bem satisfatório pelo visto.
Vou começar a implementar o uso de índices nas minhas consultas para ver na real como isso vai funcionar!
Muito obrigado pela ajuda amigo!
Responder
14/08/2017
Ermesom Lourenco
Fico feliz em poder ajudar Carlos.
Só te dou um toque quanto a utilização: Não exagere!
Cada novo índice requer mais espaço no banco de dados. É como se trocasse um processamento por espaço, mas dependendo da quantidade que se utiliza pode ser um tiro no pé.
Te dou a dica de sempre avaliar as consultas que irá utilizar. O Oracle por padrão já possui índices para cada nova chave primária, então já exclui a necessidade de se criar índices para ID's por exemplo, vale pesquisar para o SQLServer. Outro detalhe é que, se há um índice para CPF e outro para NOME, ao buscar where CPF = X and NOME = Y, talvez o banco de dados não utilize o índice, tendo em vista que o ganho poderá ser pouco (não há como ter certeza se irá ou não utilizar). Já se esta consulta for sempre feita, é recomendado criar um índice (CPF, NOME), que neste caso sempre será utilizado (haverá um hash para as duas colunas juntas).
Mas somente faça este ultimo caso se for realmente necessário. A empresa onde trabalho nem utiliza esta técnica (chamada aqui de índices perfeitos, mas não sei a nomenclatura correta).
Há ainda a possibilidade de criação de índices virtuais, nos quais existirão somente para uma sessão específica, vale a pesquisa.
Em todo caso, realmente, a perda não ultrapassa os ganhos na maioria dos casos.
Espero que, mais uma vez, tenha sido útil.
Só te dou um toque quanto a utilização: Não exagere!
Cada novo índice requer mais espaço no banco de dados. É como se trocasse um processamento por espaço, mas dependendo da quantidade que se utiliza pode ser um tiro no pé.
Te dou a dica de sempre avaliar as consultas que irá utilizar. O Oracle por padrão já possui índices para cada nova chave primária, então já exclui a necessidade de se criar índices para ID's por exemplo, vale pesquisar para o SQLServer. Outro detalhe é que, se há um índice para CPF e outro para NOME, ao buscar where CPF = X and NOME = Y, talvez o banco de dados não utilize o índice, tendo em vista que o ganho poderá ser pouco (não há como ter certeza se irá ou não utilizar). Já se esta consulta for sempre feita, é recomendado criar um índice (CPF, NOME), que neste caso sempre será utilizado (haverá um hash para as duas colunas juntas).
Mas somente faça este ultimo caso se for realmente necessário. A empresa onde trabalho nem utiliza esta técnica (chamada aqui de índices perfeitos, mas não sei a nomenclatura correta).
Há ainda a possibilidade de criação de índices virtuais, nos quais existirão somente para uma sessão específica, vale a pesquisa.
Em todo caso, realmente, a perda não ultrapassa os ganhos na maioria dos casos.
Espero que, mais uma vez, tenha sido útil.
Responder
15/08/2017
Carlos Arantes
Com certeza foi muito útil! Muito obrigado pela ajuda Ermesoml :)
Responder
Clique aqui para fazer login e interagir na Comunidade :)
