T-SQL service d'indexation optimisation SQL openquery

Question

Scénario:

J'utilise un proc (SQL Server Management Studio) stockées T-SQL pour retourner la recherche correspondant à des documents texte à l'aide du service d'indexation MS et ce (simplifié) query:

SELECT * 
FROM openquery( 
    filesystem2, 
    'SELECT 
    Path, Rank, Filename 
    FROM 
    SCOPE('' "e:\test\documents" '') 
    WHERE 
    CONTAINS('' FORMSOF (INFLECTIONAL, "test") '') 
    ') b 

Cette requête a cessé de fonctionner correctement il y a quelques jours. Bien que n'étant pas entièrement justifié, il semble que l'interaction entre le cache de propriété et l'index principal ne fonctionne pas correctement car je peux trouver les documents désirés soit par:

1) en supprimant le paramètre SCOPE (c'est-à-dire en utilisant simplement "FROM SCOPE" () » comme la clause FROM

2) éliminer la clause WHERE (et en gardant la fonction SCOPE comme est)

Alors, je peux « trouver » les documents souhaités par tout contenu ou en tout lieu, mais pas par utilisant les deux ensemble.

Une option serait de réindexer le catalogue, mais la réindexation n'est, pour l'instant, qu'une option de dernier recours.

Cela étant dit, je réécrit la requête pour exclure la portée spécifiée et comprennent une somme supplémentaire de la clause WHERE:

SELECT * 
FROM openquery( 
    filesystem2, 
    'SELECT 
    Path, Rank, Filename 
    FROM 
    SCOPE() 
    WHERE 
    CONTAINS('' FORMSOF (INFLECTIONAL, "test") '') and 
    Path like ''%e:\test\documents%'' 
    ') b 

Cette requête renvoie les documents appropriés lors de la recherche. Cependant, j'étais préoccupé par un impact potentiel sur les performances utilisant le mot-clé LIKE. Donc, j'ai étudié le plan d'exécution de chaque requête, mais ils étaient exactement les mêmes ... ce qui me dit 1 de deux choses:

1) le composant de requête du service d'indexation optimise les deux requêtes de manière à les rendre égal.

2) L'analyseur de requêtes ne fournit pas de retour précis pour les requêtes distantes lorsqu'aucune table DB n'est référencée.

Questions (sans ordre particulier). Quelqu'un a-t-il un aperçu de ce qui suit?:

1) Qu'est-ce qui pourrait causer le comportement du problème original entre le cache de propriétés et l'index principal décrit dans le scénario ci-dessus?

2) En ce qui concerne le plan d'exécution,

a) Would the Querying Component process/optimize both queries the same? 

b) Can Sql Server Management Studio provide execution plan feedback for openquery queries that do not reference any DB tables? 

3) Enfin, Quelle requête est plus efficace/plus rapide, et pourquoi?

a) i.e. should I use the second one because it solves my problem? 

Merci!

Answer 1

null valeurs peuvent être un problème. Je ne suis pas sûr de ce cas précis, mais parfois, y compris "where xxx is not null" peut faire une réelle différence.

Une autre option est parfois de mettre où les conditions sur la table après la requête ouverte select aaa, bbb from openquery(.....) where aaa = zzz. (Pour un meilleur style, sélectionnez les colonnes dont vous avez besoin au lieu de *.Pour ce qui est plus efficace ou plus rapide, vous devrez peut-être envelopper la requête avec un processus de minutage simple et juger par vous-même si vous ne pouvez pas utiliser les métriques fournies par les messages par défaut de gestion SQL. En fin de compte, tant que votre requête fonctionne et ne rompt pas les normes que vous avez définies pour votre projet, oui - utilisez-la.