Onde posso encontrar alguma orientação sobre estratégias de índice?


22

A maioria de nós provavelmente concorda que o uso de índices de banco de dados é bom. Muitos índices e desempenho podem realmente ser prejudicados.

Como regra geral, quais campos devem ser indexados?
Quais campos não devem ser indexados?
Quais são as regras para o uso de índices e, ao mesmo tempo, encontrar um equilíbrio entre índices demais e insuficientes para obter melhorias de desempenho, não degradação?


7
Para obter orientação sobre indexação, use-the-index-luke.com
Mike Sherrill 'Cat Recall'

Respostas:


24

Baixo

A regra "muitos índices" é um pouco enganadora, eu acho.

Grandes

Dado que o banco de dados médio está em torno de 98%, as leituras (ou superiores) precisam ser otimizadas. Um INSERT é uma leitura se houver um índice exclusivo, por exemplo. Ou o WHERE em uma atualização. Uma vez eu li que mesmo um banco de dados com muita gravação ainda é de 85%.

O que você tem é uma indexação de baixa qualidade. Exemplos:

  • índices agrupados em largura (especialmente no SQL Server)
  • indexado em cluster não monotônico
  • índices sobrepostos (por exemplo, cold, coleecold, cole, colf)
  • muitos índices de coluna única (também sobrepostos a índices mais úteis) que são inúteis para suas consultas
  • sem INCLUI, sem cobertura (por exemplo, todos os índices de coluna única)
  • ...

Observe que é bastante comum ter índices várias vezes maiores que os dados reais, mesmo em sistemas OLTP.

Geralmente, eu começaria com o

  • índice agrupado (geralmente PK)
  • índices exclusivos (sem restrições, não podem ser cobertos)
  • colunas de chave estrangeira

Então eu olhava para:

  • consultas comuns e ver o que eu preciso. Uma consulta em execução a cada segundo precisa de ajuste. O relatório no domingo às 4 da manhã pode esperar.
  • com o SQL Server, as DMVs de índice ausentes ponderadas

Dizendo isso, quebrei essas regras para alguns sistemas depois de ver como as coisas funcionavam (10 bilhões de linhas depois) para ajustar um sistema. Mas nunca consideraria não indexar, a menos que demonstrasse por que estou fazendo isso.


2
De onde você conseguiu esses números? 98% parece muito alta, especialmente na época de "grandes dados" (aka loja de tudo e espero que seja útil algum dia)
rm

7

Você deve analisar o uso e o carregamento do banco de dados e identificar gargalos devido à falta de índices - ou devido a muitos índices. Então você precisa escolher o índice adequado - e isso exige um bom conhecimento das técnicas específicas de indexação de banco de dados.


7

Simplesmente uma das melhores séries de artigos escritos sobre quais índices escolher e por que seria de Gail Shaw. Você pode encontrar os artigos clicando aqui

A pergunta que você faz pode ser respondida de 50 maneiras diferentes. Na verdade, tudo se resume aos dados que você possui e como eles serão consultados. Uma regra geral é que você sempre deve ter um índice em cluster em cada tabela para evitar pilhas. Os índices agrupados geralmente devem ser o menor possível. Se a tabela tiver um índice em cluster, todos os registros de índice nas páginas folha do índice não em cluster armazenarão o valor do registro do respectivo índice em cluster para pesquisas de indicadores. Se uma tabela for um heap, o SQL criará um identificador exclusivo para pesquisas de indicadores. Não me lembro do tamanho de 8 ou 16 bytes. Isso pode acabar sendo um tipo de dados muito maior do que um INT. Imagine ter 8 índices não agrupados em uma tabela de heap.


Apenas uma observação para os leitores: o MS SQL "bookmark lookup" é equivalente ao "ACCESS BY ROWID" do Oracle. Veja stackoverflow.com/a/820731/122727
kubanczyk

5

Quero acrescentar aqui que bancos de dados diferentes exigem estratégias diferentes. Vamos comparar o MySQL com o InnoDB e o PostgreSQL, por exemplo.

InnoDB

As tabelas do InnoDB são basicamente um índice de árvore b da chave primária, que são estendidas para incluir as informações da linha na entrada do índice. As varreduras de ordem física não são suportadas e todas as varreduras ocorrem em ordem lógica. Isso significa duas coisas:

  1. Uma varredura seqüencial no Innodb gera muitas E / S de disco aleatórias e

  2. O índice da chave primária deve ser percorrido, independentemente de alguém estar usando um índice secundário.

  3. As pesquisas de chave primária são mais rápidas neste modelo do que em qualquer outra abordagem.

Nesse caso, é muito importante indexar campos suficientes em tabelas de várias páginas. A regra típica é indexar tudo o que você deseja filtrar.

PostgreSQL

O PostgreSQL usa arquivos de heap, uma tabela por arquivo (algumas tabelas podem ter muitos arquivos) onde as tuplas são alocadas a partir do espaço livre desse heap. Varreduras de ordem física são suportadas. Para que uma varredura de ordem lógica funcione, é necessário adicionar um índice.

As chaves primárias no PostgreSQL são basicamente um subconjunto de índices exclusivos, onde nenhum valor pode ser NULL. Restrições UNIQUE são feitas usando índices implícitos e vários outros tipos de índice são suportados com operações diferentes possíveis no índice.

Isso significa:

  1. As pesquisas de chave primária, assumindo que uma tabela razoavelmente grande exija um arquivo de índice e um arquivo de tabela. Isso é significativamente mais lento que a abordagem do MySQL, onde o índice só deve ser percorrido e a linha está contida no índice.

  2. As verificações de ordem física têm um desempenho muito melhor, reduzindo a E / S aleatória do disco, onde um número significativo de linhas deve ser processado.

  3. Varreduras de índices secundários têm melhor desempenho do que o MySQL porque apenas um índice deve ser percorrido para chegar à parte física da tabela.

Nesse modelo, os índices geralmente são necessários, mas o planejador tem mais liberdade quando usar um índice, e as implicações de não usá-lo são geralmente menos graves. As tabelas são geralmente otimizadas (em vez de se especializarem em pesquisas pkey) e, portanto, são necessários menos índices.

TL; DR

Conheça o seu RDBMS.



2

Mesmo com todos os links acima, você precisa examinar o que Kimberly Tripp escreveu sobre os cuidados, alimentação e uso de índices.

Para iniciantes, siga este link para a coleção de Kimberly de suas postagens no blog relacionadas ao índice. Você pode explorar tópicos específicos usando os widgets "Nesta página" e "Categorias" no lado esquerdo da janela do navegador.

Há muita informação aqui, mas não se assuste com isso.

A página Sobre da Kimberly está aqui


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.