Performances SQL Server FTS après l'ajout de nombreux loggings

Nous avons une application web qui permet aux clients de gérer de grandes lists de noms. Pour effectuer une search sur ces lists, nous utilisons le FTS de SQL Server 2008, qui fonctionne généralement bien. Notre plus grand client count 900 000 noms et bénéficie de time de search inférieurs à la seconde.

Pour un autre nouveau client, cependant, j'ai récemment importé 150 000 noms, et la performance est terrible (comme dans, server terriblement débilitant). J'ai vérifié l'indexeur de text intégral et il prétend avoir récemment complété une exploration.

En regardant les plans d'exécution, je remarque que dans le cas rapide (pour le client plus grand), SQL Server fait d'abord le FTS, puis l'index cherche sur le résultat. Pour le client le plus récent, il search d'abord un indice (150 000 fois, apparemment, pour les nouveaux loggings) et ALORS le FTS.

J'ai donc essayé l'indice WITH (INDEX (MyFullTextIndex)), mais SQL Server dit que l'index n'existe pas. Apparemment, il ne considère pas ces indices FTS comme des indices "réels". Comment puis-je forcer SQL Server à toujours utiliser le FTS en premier?

MISE À JOUR: J'ai essayé de régénérer les statistics, en vain. Mêmes problèmes de performance.

Voici les plans d'exécution:

Performances FAST: http://frameaction.com/LLExecutionPlan01.sqlplan

Performance SLOW: http://frameaction.com/LLExecutionPlan18.sqlplan

J'ai essayé d'append l'indice "OPTIMIZE VALUE FOR UNKNOWN" à la fin de ma requête (j'ai aussi dû append une variable fictive à la requête pour avoir quelque chose à referencer dans l'indice). Jusqu'à présent, il semble fonctionner correctement. Je suis un peu nerveux à propos des conseils, et je suis toujours à la search d'une meilleure solution, mais pour l'instant cela fonctionne.

Vérifiez les statistics sur chaque table. Les deux servers peuvent avoir des sets de statistics différents, car SQL génère automatiquement des statistics en fonction de vos parameters. S'il a créé des statistics différentes, il choisira différents plans de requête pour les requêtes.

Ensuite, assurez-vous que vos statistics sont mises à jour. Vous findez des informations sur la mise à jour de vos statistics pour chaque table dans la documentation en ligne:

http://msdn.microsoft.com/en-us/library/ms187348.aspx

Je mettrais à jour avec fullscan pour m'assurer d'avoir de bonnes données.

Enfin, si aucun de ces travaux, exécutez la requête dans SQL Server Management Studio, mais utilisez l'option "Include Actual Query Plan". Puis cliquez avec le button droit n'importe où sur le plan de requête et choisissez Enregistrer en XML. Postez les deux plans de requête différents quelque part sur le Web, et nous verrons quelle est la différence et pourquoi.

Vous n'êtes pas sûr que cela vous aidera mais vous pouvez essayer d'utiliser CONTAINSTABLE – qui vous permet de changer l'ordre de jointure.

SELECT customer_id FROM clients WHERE CONTIENT (nom de l'user, 'Foobar')

Devient

SELECT customer_id FROM Clients AS FTTABLE INNER JOIN CONTAINSTABLE (Clients, nom de l'user, 'Foobar') FTINDEX SUR FTINDEX. [Clé] = FTTABLE.customer_id

Je n'ai jamais utilisé le service FTS de SQL Server, mais comme le dit le premier postr, j'ai constaté que lors du chargement des entrepôts de données ou des bases de données, certaines requêtes qui tournaient correctement étaient très lentes après le chargement d'une grande quantité de données. L'exécution de sp_updatestats après chaque chargement a corrigé le problème (même si l'option de database de mise à jour automatique des statistics est cochée (ce qui est le cas par défaut).

L'index FTS est une boîte noire que le server sql ne peut joindre qu'à ses résultats, il search toujours la table entière sans tenir count des clauses where ou des jointures internes. Un moyen que j'ai trouvé pour augmenter la performance d'une search FT est en effectuant la jointure et toutes les clauses non basées sur les parameters dans une vue liée au schéma et la search d'un index de text complet sur cette vue.