2010-11-02 48 views
4

J'ai un problème avec l'indexation de texte intégral sur SQL Server 2008 x64.La recherche de texte intégral "Contient" est plus lente que "Comme%"

J'ai trois tables:

TableA avec 90 000 lignes

TableB avec 12 000 000 lignes

TableC avec 22 000 000 lignes

j'ai créé des catalogues FTS avec autopopulation.

Quand j'ai demandé TableA:

Select * from TableA where Contains(field1, '"j*"') 

Je vois moins de disques 11000 1 seconde

Mais quand j'ai demandé TableB ou TableC avec la même requête, je vois 250 enregistrements en 2 secondes. C'est évidemment très lent.

L'interrogation avec "comme%" au lieu de "contient" s'exécute moins de 1 seconde pour les mêmes tables.

Le problème peut-il exister en raison des grandes tables B et C? La tableA a été interrogée avec succès.

Peut-être que ces tables ont besoin de plus de temps pour l'indexation? (Mais ils sont l'indexation (peuplant) 3 jours déjà)

Quelques détails:

Pour les tableaux B et CI toujours voir "État de la population = notifications de traitement" (9)

propriété "TableFulltextDocsProcessed" augmente toujours

(My SQL Server ont une instance en miroir.)

+1

* "mais ils indexent (peuplent) déjà 3 jours" * <- vous dites que l'index n'est pas encore terminé? Alors bien sûr, c'est plus lent sans index. Vous avez également dit que le statut est toujours "traitement des notifications". Est-ce que le serveur SQL affamé MSFTESQL/MSSEARCH de la mémoire, peut-être c'est pourquoi il faut des âges pour compléter l'index de texte intégral? –

+0

"mais ils indexent (peuplent) 3 jours déjà" <- L'ajout d'éléments devrait être terminé: la propriété "Item Count" du catalogue FTS est égale au nombre de lignes nécessaires et j'attends 3 jours et l'interrogation est encore lente. Ce qui est étrange, c'est que TableA avec peu d'enregistrements est interrogée avec succès. Donc je pense que les tableaux B et C ont besoin de plus de temps pour construire du cache ou quelque chose ... A propos des paramètres de mémoire: ils sont par défaut. Et je ne vois aucun problème de mémoire sur le serveur. Mon serveur possède également une instance en miroir. Cela peut-il influencer mon problème? –

Répondre

1

Je ne sais pas si votre requête contient vraiment utiliser l'index de texte intégral. Je pense qu'il doit faire une analyse de table complète. Comme je l'ai compris les mots index de l'index en texte intégral et le mot stem dans différentes langues. Votre comme requête

Select * from TableA where Contains(field1, '"j*"') 

n'a que le caractère « j » en si vous avez fait la même recherche avec

Select field1 from TableA where Contains(field1, 'fish') 

par rapport à

Select field1 from TableA where field1 like '%fish%' 

Dans cette citation, ils parlent beaucoup de mots pas de caractères. SQL Server 2005 Full-Text Search: Internals and Enhancements

recherche en texte intégral permet l'indexation rapide et flexible pour par mots-clés requête de données de texte stockées dans une base de données SQL Server . Contrairement à LIKE prédicat, qui ne fonctionne que sur motifs de caractères, les requêtes en texte intégral effectuer une recherche linguistique contre ces données, fonctionnant sur des mots et des phrases basées sur des règles d'une langue particulière.

Je me demande donc si j * fonctionne si l'expression: « j » doit être un mot dans les langues que le texte intégral est utilisé avec .. voir CONTAINS (Transact-SQL)

Indique une correspondance de mots ou d'expressions commençant par le texte spécifié. Entourez un terme préfixe à deux guillemets (« ») et ajouter un astérisque () avant la désinence guillemet, de sorte que tout le texte en commençant par le terme simple spécifié avant l'astérisque est adapté. La clause doit être spécifiée de la façon suivante: CONTAINS (colonne, '"text"'). L'astérisque correspond à zéro, un ou plusieurs caractères (du mot racine ou mots dans le mot ou la phrase)

Qu'est-ce que les plans d'exécution ressemblent?