Pergunta

Fundo: Eu tenho uma tabela com as entradas de 5 milhões de endereços que eu gostaria de procurar diferentes campos (nome do cliente, nome de contato, CEP, cidade, telefone, ...), até 8 campos. Os dados são bastante estável, máximo 50 muda de um dia, por isso quase apenas acesso de leitura.

O usuário não é suposto para me dizer de antemão o que ele está procurando, e eu também quero o apoio de pesquisa combinada (E-concatenação de termos de pesquisa). Por exemplo, "lincoln + lond" deve procurar todos os registros que contêm ambos os termos de pesquisa em qualquer um dos campos de pesquisa, também as entradas começando com qualquer um dos termos (como "London" neste exemplo).

Problema: Agora eu preciso escolher uma estratégia de indexação para esta tabela de pesquisa. (Como uma nota lateral: Eu estou tentando alcançar o tempo de resposta sub-segundo, pior tempo de resposta deve ser de 2 segundos.) O que há de melhor em termos de perfomance:

  1. Faça um índice combinado de todas as colunas Queryable (precisaria 2 deles, como limite de índice de 900 bytes atingido)
  2. Coloque índices individuais em cada uma das colunas Queryable
  3. Faça um índice de texto completo nas colunas Queryable e uso de texto completo da consulta

Estou ponto 1 descartando, uma vez que não parecem ter qualquer vantagem (utilização do índice será limitada e não haverá "busca de índice", porque nem todos os campos caber em um único índice).

Pergunta: Agora, eu deveria usar os vários índices único variante ou devo ir com o índice de texto completo ? Existe qualquer outra forma para obter a funcionalidade acima mencionada?

Foi útil?

Solução 4

Para responder a minha própria pergunta:

Eu escolhi a opção "vários índices individuais". I terminou ter um índice para cada uma das colunas consultados, cada índice contendo apenas a própria coluna. A busca funciona muito bem com tempos de resposta na maior parte subsecond. Às vezes, leva até 2-3 segundos, mas eu estou atribuindo-o para o meu servidor de banco de dados (vários anos velho laptop com 3GB de RAM e disco lento).

Eu não testar a opção de texto completo, uma vez que não era mais necessário (e eu não tenho o tempo para fazê-lo.)

Outras dicas

Tente ambos e ver qual é mais rápido em seu sistema. Existem algumas regras duras e rápidas para otimizações de banco de dados, ele realmente depende do seu ambiente.

Originalmente, eu estava prestes a sugerir indo com STF como que tem um monte de forte desempenho apresenta indo para ele. Especialmente quando você lidar com consultas variadas. (Por ex. X e y. X PERTO y, etc ..).

Mas antes de eu começar a divagar com o pro de FTS, Acabei de verificar a sua versão do servidor -.> Sql2000

coitada. STF estava de volta muito simples, em seguida, para ficar com vários índices único .

Nós usamos sql2008 e ... balança.

Oh, btw. você sabia que sql2008 (edição gratuita) tem FTS nele? É possível fazer o upgrade?

Indo de sql2000 -.> Sql2008 é muito vale a pena, se você puder

Mas sim, vara com o seu M.S.I. opção.

Eu concordo com Grauenwolf, e eu gostaria de acrescentar uma nota sobre índices. Tenha em mente que se você usar uma sintaxe como o seguinte:

SELECT field1, field2, field3
FROM table
WHERE field1 LIKE '%value%

Em seguida, nenhum índice será usado de qualquer maneira durante a pesquisa em campo1 e você tem que recorrer a um índice de texto completo. Por uma questão de exaustividade, a sintaxe acima retorna todas as linhas onde campo1 contém valor (não necessariamente no início). Se você tem que procurar por "contém", um índice de texto completo é provavelmente mais apropriado.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top