Служба индексирования T-SQL Оптимизация открытых запросов SQL

Question

Сценарий:

Я использую хранимую процедуру T-SQL (Sql Server Management Studio) для возврата совпадений поиска для текстовых документов с использованием службы индексирования MS и этого (упрощенного) запроса:

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

Этот запрос перестал работать должным образом несколько дней назад.Хотя это и не полностью обосновано, похоже, что взаимодействие между кэшем свойств и главным индексом не работает должным образом, поскольку я могу найти нужные документы любым из способов:

1) удаление параметра SCOPE (т.е.просто используя «FROM SCOPE()» в качестве предложения FROM

2) удаление предложения WHERE (и сохранение функции SCOPE как есть)

Таким образом, я могу «найти» нужные документы только по содержимому или только по локали, но не используя оба вместе.

Одним из вариантов может быть переиндексация каталога, но на данный момент переиндексация является лишь крайней мерой.

При этом я переписал запрос, исключив указанную область SCOPE и включив дополнительное предложение WHERE:

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

Этот запрос возвращает правильные документы при поиске.Однако меня беспокоило потенциальное снижение производительности при использовании ключевого слова LIKE.Итак, я исследовал план выполнения каждого запроса, но они были абсолютно одинаковыми... что говорит мне об одном из двух:

1) Компонент запросов службы индексирования оптимизирует оба запроса таким образом, чтобы сделать их равными.

2) Анализатор запросов не обеспечивает точную обратную связь для удаленных запросов, когда нет ссылок на таблицы БД.

Вопросы (в произвольном порядке).Есть ли у кого-нибудь понимание следующего?:

1) Что может вызвать поведение исходной проблемы между кэшем свойств и главным индексом, описанное в приведенном выше сценарии?

2) Что касается плана реализации,

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) Наконец, какой запрос более эффективен/быстрее и почему?

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

Спасибо!

Answer 1

нулевой ценности могут быть проблемой.Я не уверен насчет этого конкретного случая, но иногда в том числе "where xxx is not null"может реально изменить ситуацию.

Иногда другой вариант — поместить условия в таблицу после открытого запроса.select aaa, bbb from openquery(.....) where aaa = zzz.(Для лучшего стиля выберите нужные столбцы вместо *.

Что касается того, что более эффективно или быстрее, вам, возможно, придется обернуть запрос простым процессом синхронизации и судить сами, если вы не можете использовать метрики, предоставляемые сообщениями по умолчанию управления SQL.

В конце концов, если ваш запрос работает и не нарушает никаких стандартов, которые вы установили для своего проекта, да — используйте его.