SQL Server 05, который является оптимальным, LIKE% <term>% или CONTAINS () для поиска в большом столбце - PullRequest
Новая
       26

SQL Server 05, который является оптимальным, LIKE% <term>% или CONTAINS () для поиска в большом столбце

4 голосов
/ 16 марта 2010

У меня есть функция, написанная другим разработчиком, которую я пытаюсь изменить для немного другого использования. Он используется SP для проверки того, существует ли определенная фраза в текстовом документе, хранящемся в БД, и возвращает 1, если значение найдено, или 0, если его нет. Это запрос: 

SELECT @mres=1 from documents where id=@DocumentID
 and contains(text, @search_term)

Документ содержит в основном XML, а search_term - это GUID, отформатированный как nvarchar (40).

Мне кажется, это работает довольно медленно (на выполнение этой части процесса уходит 5-6 секунд), но в том же файле сценария есть и вышеприведенная версия, приведенная выше 

SELECT @mres=1 from documents where id=@DocumentID
and textlike '%' + @search_term + '%'

Эта версия работает НАМНОГО быстрее, занимая 4 мс по сравнению с 15 мс для первого примера.

Итак, мой вопрос: зачем использовать первое вместо второго? Я предполагаю, что у этого разработчика (который больше не работает со мной) была веская причина, но в данный момент я изо всех сил пытаюсь найти его ..

Возможно, это связано с полнотекстовой индексацией? (это - рабочая БД, с которой я работаю, так что производственная версия может лучше индексироваться ...) Я не особо разбираюсь в FTI, поэтому в данный момент не совсем уверен. Мысли / идеи?

Ответы [ 2 ]

1 голос
/ 16 марта 2010

Обновление: Aggg - все мои ответы неверны!

Да, CONTAINS действительно использует полнотекстовый поиск (см. http://msdn.microsoft.com/en-us/library/ms187787.aspx) и поэтому должен быть быстрым (или, по крайней мере, он должен правильно масштабироваться)

Причина, по которой вторая версия (с использованием LIKE) может быть быстрее, заключается в том, что ваша таблица не содержит много строк - вызов полнотекстового движка для поиска потребует небольших дополнительных затрат, что может означать, что использование LIKE незначительно быстрее для небольших столов.

С другой стороны, если выполнение верхнего запроса занимает 5-6 секунд, я бы сказал, что, возможно, что-то где-то не так - снова попробуйте посмотреть план выполнения.

0 голосов
/ 16 марта 2010

Всегда будет случай, когда один вариант будет быстрее другого, и наоборот. Лучшим вариантом будет протестировать тот же запрос на производстве и увидеть разницу. Для такого рода тестирования производительности я бы рекомендовал использовать профилировщик и выполнять каждый запрос несколько раз, а для сравнения взять среднее значение

...