Les performances des requêtes de l'indice combiné par rapport à plusieurs index unique par rapport aux index de texte intégral

Question

Contexte: J'ai une table avec 5 millions d'entrées d'adresse que je voudrais rechercher différents champs (nom du client, le nom de contact, zip, ville, téléphone, ...), en hausse 8 champs. Les données sont assez stables, au maximum 50 change un jour, afin de lire presque seul accès.

L'utilisateur n'est pas censé me dire à l'avance ce qu'il recherche pour, et je veux aussi le soutien de la recherche combinée (ET-concaténation des termes de recherche). Par exemple, « lincoln + lond » doit rechercher tous les documents contenant les termes de recherche dans l'un des champs de recherche, également les entrées commençant par l'un des termes (comme « London » dans cet exemple).

Problème: Maintenant je dois choisir une stratégie d'indexation pour cette table de recherche. (Comme une note de côté: Je suis en train de réaliser des sous-deuxième temps de réponse, le pire temps de réponse devrait être de 2 secondes.) Quoi de mieux en termes de perfomance:

1. Faites un indice combiné de toutes les colonnes interrogeables (aurait besoin 2 d'entre eux, comme limite d'index de 900 octets atteint)
2. Mettre les index sur chacune des colonnes interrogeables
3. un index de texte intégral sur les colonnes interrogeables et utiliser requête texte intégral

Je jeter le point 1, car il ne semble pas avoir un avantage (utilisation d'index sera limité et il n'y aura pas de « recherche d'index », car tous les champs intègrent dans un seul index).

Question: Maintenant, dois-je utiliser les plusieurs index unique variante ou devrais-je aller avec l'index de texte intégral ? Y at-il toute autre manière pour obtenir la fonctionnalité mentionnée ci-dessus?

Answer 1

Pour répondre à ma propre question:

J'ai choisi l'option « multiples index unique ». Je finis ayant un index pour chacune des colonnes interrogées, chaque index ne contenant que la colonne elle-même. La recherche fonctionne très bien avec des temps de réponse la plupart du temps la seconde. Parfois, il faut jusqu'à 2-3 secondes, mais je l'attribuer à mon serveur de base de données (plusieurs années avec un ordinateur portable vieux et 3Go Ram disque lent).

Je n'ai pas testé l'option texte intégral car il n'a pas été plus nécessaire (et je n'ai pas le temps de le faire.)

Answer 2

Essayez les deux et voir qui est plus rapide sur votre système. Il y a peu de règles et rapides pour l'optimisation des bases de données, cela dépend vraiment de votre environnement.

Answer 3

A l'origine, j'étais sur le point de proposer d'aller avec FTS comme cela a beaucoup de bonnes performances fonctionnalités pour lui. Surtout quand vous traitant de questions diverses. (P. X et y. X y NEAR, etc ..).

Mais avant que je commence à radoter avec les pros de FTS, je viens de vérifier votre version du serveur -.> SQL2000

pauvre. FTS était très simple à l'époque, mieux vaut donc rester avec plusieurs index simples .

Nous utilisons SQL2008 et ... il roches.

Oh, btw. saviez-vous que SQL2008 (édition gratuite) a FTS en elle? Est-il possible de mettre à niveau?

Voulez-vous profiter de SQL2000 -.> SQL2008 est très en vaut la peine, si vous le pouvez

Mais oui, le bâton avec votre M.S.I. option.

Answer 4

Je suis d'accord avec Grauenwolf, et je voudrais ajouter une note sur les index. Gardez à l'esprit que si vous utilisez une syntaxe comme suit:

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

Alors pas d'index sera utilisé de toute façon lors de la recherche sur field1 et vous devez recourir à un index de texte intégral. Par souci d'exhaustivité, la syntaxe ci-dessus renvoie toutes les lignes où field1 contient valeur (pas nécessairement au début). Si vous devez rechercher « contient », un index de texte intégral est probablement plus approprié.