olá,
estou usando mysql 4.1.
qual a vantagem dos indices nos bancos de dados?
qual a diferença entre indices e chaves?
tenho uma tabela que não raro irei consultar ordenado por uma string grande, é nessas situações que se deve usar indices?
Pense assim: quando você quer achar um tópico de um livro, você o folheia todo até achar ou procura no índice? (se ficou com a primeira opção é porque o livro é pequeno e bem conhecido - isso nem sempre acontece com seu banco de dados 
).
Entonces, índice no banco é igual índice em qualquer lugar … de algum modo (isso depende do tipo de índice e outras coisitas mais) o banco “organiza” o conteúdo de determinada coluna(s) para facilitar a busca.
Ah, então vou colocar todos os campos no índice e qualquer busca vai ser ajato? :roll: ehehe nonnon, quer dizer, sim, a busca será, mas qualquer instrução que altere o valor de uma coluna índice (inclui inserção e remoção) é mais demorada porque o banco precisa além de colocar a informação na estrutura da tabela também atualizar o(s) indice(s).
Entendeu?
valeu pelas dicas, mas vale a pena usar quando?
Quando vc tem um volume muito maior de pesquisas do que de escrita na base
Indices aceleram a consulta das colunas envolvidas, simples assim.
Mas se Mal usadas…NEGRADA nem fale… ou seja não ande colocando índices como um louco em qualquer campo 
… pode afetar o desempenho do banco… eu costumo usar 1 por tabela “Se necessário”
[quote=kartler]Mas se Mal usadas…NEGRADA nem fale… ou seja não ande colocando índices como um louco em qualquer campo … pode afetar o desempenho do banco… eu costumo usar 1 por tabela “Se necessário”
[/quote]
Tabelas com menos de 1 índice provavelmente não deveriam existir e mais parece sinal de falha do DBE. Sem um índice na PK qualquer operação de DML vai ser uma carroça pq vai exigir full table scan sempre.
Use índices de acordo com as suas necessidades de performance e características das suas consultas.
Via de régra todas FKs e PKs devem ser indexadas, isso garante performance razoavel pra todas operações de DML.
PKs devem ser indexadas? elas não são indexadas naturalmente?
Boa pergunta… Acho que depende do banco. No MySQL eu não sei, mas no PostgreSQL são sim.
Boa pergunta… Acho que depende do banco. No MySQL eu não sei, mas no PosgretSQL são sim.[/quote]
Firebird com certeza são…
mas eu acredito (não tenho 100% de certeza) que todos os bancos são
A explicação do smota foi muito boa, é por aí mesmo.
Agora imagine que você tenha duas situações:
Livro 1 - 6 páginas - 3 capítulos
Livro 2 - 540 páginas - 43 capítulos
Você precisa consultar 1 capítulo em cada livro.
Imagine uma consulta com dois tempos:
1- buscar o índice (qual página está o capítulo 3?)
2- com o índice buscar os dados (quaol o título do capiítulo 3 ?)
Uma consulta completa é a soma desses dois tempos.
No livro 2 até é viável vc usar o índice, mas no livro 1
acaba sendo inviável, pois se vc folhear o livro inteiro
vc acha o capítulo que procura tranquilamente sem usar o índice.
Então temos um novo meio de consulta, que é:
1-buscar os dados folheando o livro todo até achar
Em banco de dados a conta que se faz é a mesma,
assim como os métodos.
As vezes uma tabela é tão pequena que se usar o índice
a consulta fica lenta, e o banco de dados acaba ignorando
esse método e varrendo a tabela inteira. Esse método é
chamado de full-table-scan.
Portanto , se ficar na dúvida, crie o índice e faça o teste.
No Oracle vc pode deixar ele decidir se vale a pena usar
o índice, ou simplesmente obrigar o banco de dados a faze-lo
(usando os chamados “hints” no SELECT).
Nos outros bancos não sei como funciona.
[quote=boaglio]No Oracle vc pode deixar ele decidir se vale a pena usar
o índice, [/quote]
No Sybase (argh) tambem eh assim. Mas acho que todos devem funcionar dessa maneira - em tabelas pequenas com table-scan e tabelas grandes com indices (ai entram os algoritmos de analise de quando ir por um ou por outro caminho).
Marcio Kuchma
Se é assim então é interessante sempre definir índices, independente do tamanho da tabela, e o SGBD que se encarregue de decidir se vai usar ou não esses índices…
A ordenação não interfere em nada no uso do indice. O banco não ordena antes de retornar entao teu where será executado como se nao existisse o order by, somente com os dados retornados é que ele serão ordenados. Ai nao faz diferenca ter indice ou nao.
Boa pergunta… Acho que depende do banco. No MySQL eu não sei, mas no PostgreSQL são sim.[/quote]
Em bancos de dados sim, agora no MySQL já não sei. :lol:
[quote=kuchma][quote=boaglio]No Oracle vc pode deixar ele decidir se vale a pena usar
o índice, [/quote]
No Sybase (argh) tambem eh assim. Mas acho que todos devem funcionar dessa maneira - em tabelas pequenas com table-scan e tabelas grandes com indices (ai entram os algoritmos de analise de quando ir por um ou por outro caminho).
Marcio Kuchma[/quote]
Detalhes, no Oracle e em qualquer banco que use tuning de query por cost e nao por rule só é eficaz se o dba coleta as estatistica das tabelas regularmente, fora isso vira uma carroça.
[quote=boaglio]
Agora imagine que você tenha duas situações:
Livro 1 - 6 páginas - 3 capítulos
Livro 2 - 540 páginas - 43 capítulos
Você precisa consultar 1 capítulo em cada livro.
Imagine uma consulta com dois tempos:
1- buscar o índice (qual página está o capítulo 3?)
2- com o índice buscar os dados (quaol o título do capiítulo 3 ?)
Uma consulta completa é a soma desses dois tempos.
No livro 2 até é viável vc usar o índice, mas no livro 1
acaba sendo inviável, pois se vc folhear o livro inteiro
vc acha o capítulo que procura tranquilamente sem usar o índice. [/quote]
Bom em teoria seria isso mesmo, mas tem uns detalhes ai. Primeiro do indice para os dados o banco não faz busca por loop ele vai direto por endereco fisico de memoria, entao não existe tempo de consulta, somente o tempo de busca no hd.
Se é assim então é interessante sempre definir índices, independente do tamanho da tabela, e o SGBD que se encarregue de decidir se vai usar ou não esses índices…[/quote]
E se ele resolve nunca usar, e tua tabela tem uma grande quantidade de inser e delete como fica? Não acha que é meio arriscado essa tática?
Algumas coisas que devem ser levadas em consideração.
Indices sao bons para consulta se as restricoes que serao usadas na mesma nao retornarem mais que 30% da tabela, fora isso é mais rapido ir por full scan.
Indices nao devem ser feitos separados coluna por coluna, mas sim definir bem quais colunas sempre andam juntas nos selects e criar indices compostos.
Nos where dos select nao se deve usar funcoes ou pelo menos usar o minimo possivel, isso mata a utlizacao dos indices.
]['s
oooou se isso não for possível crie o indíce com a função, funfa e aproveita o índice
muito obrigado pelas respostas
por precaução irei criar indices para PK
Naaaaaaaaao … é melhor por precaução você descobrir se o banco que vc está usando já o faz e se fizer não criar um índice já que vai ter perda de desempenho.