Служба индексирования 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 без изменений)

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

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

При этом я переписал запрос, чтобы исключить указанную ОБЛАСТЬ и добавить дополнительное предложение 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 Management.

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