Когда следует использовать полнотекстовое индексирование?

У нас есть целая куча запросов, которые "ищут" клиентов, клиентов и т. д. Вы можете искать по имени, электронной почте и т. д. Мы используем операторы LIKE следующим образом:

SELECT * 
FROM customer 
WHERE fname LIKE '%someName%'

помогает ли полнотекстовое индексирование в сценарии? Мы используем SQL Server 2005.

4 ответов


Это будет зависеть от вашей СУБД. Я считаю, что большинство систем не будут использовать полнотекстовый индекс, Если вы не используете полнотекстовые функции. (например, МАТЧ / ПРОТИВ в mySQL или FREETEXT / содержит в MS SQL)

вот хорошая статья о том, когда, почему и как использовать полнотекстовое индексирование в SQL Server:понимание полнотекстового индексирования SQL Server


FTS can помощь в этом сценарии, вопрос в том, стоит ли это или нет.

Для начала, давайте разберемся, почему LIKE может быть не самый эффективный поиск. Когда вы используете LIKE, особенно, когда вы ищете с % в начале сравнения SQL Server должен выполнить как сканирование таблицы каждой отдельной строки и байт за байтом проверка столбца, который вы проверяете.

FTS имеет некоторые лучшие алгоритмы для сопоставления данных, как и некоторые лучшие статистические данные о вариациях имен. Поэтому FTS может обеспечить лучшую производительность для сопоставления Smith, Smythe, Smithers и т. д., Когда вы ищете Smith.

это, однако, немного сложнее использовать FTS, так как вам нужно будет освоить CONTAINS vs FREETEXT и тайный формат поиска. Однако, если вы хотите выполнить поиск, где совпадают FName или LName, вы можете сделать это с помощью одного оператора вместо OR.

определить, является ли FTS чтобы быть эффективным, определите, сколько данных у вас есть. Я использую FTS в базе данных из нескольких сотен миллионов строк, и это реальная польза от поиска с LIKE, но я не использую его на каждый стол.

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


согласно моему тестовому сценарию:

  • SQL Server 2008
  • 10.000.000 строк, в каждой строке, как "слово_а слово_б wordC..."(изменяется от 1 до 30 слов)
  • выбор count (*) с CONTAINS (столбец, "wordB")
  • размер результата несколько сотен тысяч
  • размер каталога приблизительно 1.8 GB

полнотекстовый индекс находился в диапазоне 2s, тогда как как '% слово_б %' был в пределах 1-2 протокол.

но это считается, только если вы не используете никаких дополнительных критериев выбора! Е. Г. если я использовал некоторые "like' prefix%'" в столбце первичного ключа производительность была хуже, так как операция перехода в полнотекстовый индекс стоит больше, чем выполнение поиска строк в некоторых полях (если это не слишком много).

поэтому я бы рекомендовал полнотекстовый индекс только в случаях, когда вам нужно сделать "бесплатно string search " или использовать некоторые из его особенностей...


чтобы ответить на вопрос специально для MSSQL, полнотекстовая индексация будет не помощь в вашем сценарии.

чтобы улучшить этот запрос, вы можете сделать одно из следующих действий:

  1. настройте полнотекстовый каталог в столбце и используйте функцию CONTAINS ().
  2. Если вы в первую очередь искали с префиксом (т. е. соответствием с самого начала имени), вы можете изменить предикат на следующий и создать индекс столбец.

    где fname как " префикс%"

(1), вероятно, излишне для этого, если производительность запроса не является большой проблемой.