Полнотекстовый поиск

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

Полнотекстовый поиск в SQL Server и Базе данных SQL Azure позволяет приложениям и пользователям выполнять полнотекстовые запросы к символьным данным в таблицах SQL Server.

Критические изменения в SQL Server 2025

SQL Server 2025 (17.x) вводит критические изменения в Full-Text поиска.

Дополнительные сведения можно найти здесь

Основные задачи

В этой статье представлен обзор полнотекстового поиска и описаны его компоненты и архитектура. Если вы хотите немедленно приступить к работе, здесь вы найдете простые примеры задач.

Полнотекстовый поиск является необязательным компонентом ядра СУБД SQL Server. Если при установке SQL Server вы не выбрали полнотекстовый поиск, добавьте его позже, снова запустив программу установки.

Обзор

Полнотекстовый индекс включает один или несколько символьных столбцов в таблице. Эти столбцы могут содержать любой из следующих типов данных: char, varchar, nchar, nvarchar, text, ntext, image, xmlили varbinary(max) и FILESTREAM. Каждый полнотекстовый индекс индексирует один или несколько столбцов таблицы, а каждому столбцу может соответствовать определенный язык.

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

Запросы полнотекстового поиска

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

  • Одно или несколько конкретных слов или фраз (простое выражение)
  • Слово или фраза, в которых слово или слова начинаются с указанного текста (префиксный термин)
  • Словоформы конкретного слова (производное выражение)
  • Слово или фраза, расположенные рядом с другим словом или фразой (термин близости)
  • Синонимические формы конкретного слова (тезаурус)
  • Слова или фразы со взвешенными значениями (взвешенное выражение)

Полнотекстовые запросы не учитывают регистр. Например, поиск Aluminum или aluminum возвращает одинаковые результаты.

Полнотекстовые запросы используют небольшой набор предикатов Transact-SQL (CONTAINSи) и функций (FREETEXTиCONTAINSTABLEFREETEXTTABLE). Однако точная структура полнотекстовых запросов определяется целями поиска данного бизнес-сценария. Например:

  • Поиск продукта на веб-сайте электронной коммерции:

    SELECT product_id
FROM products
WHERE CONTAINS ((product_description), '"Snap Happy 100EZ" OR FORMSOF(THESAURUS,"Snap Happy") OR "100EZ"')
      AND product_cost < 200;

  • Чтобы найти кандидатов на работу, имеющих опыт работы с SQL Server:

    SELECT candidate_name,
       SSN
FROM candidates
WHERE CONTAINS ((candidate_resume), '"SQL Server"')
      AND candidate_division = 'DBA';

Дополнительные сведения см. в разделе Запросы с полнотекстовым поиском.

Сравнение запросов полнотекстового поиска с предикатом LIKE

В отличие от полнотекстового поиска, предикат LIKE Transact-SQL работает только в шаблонах символов. Кроме того, нельзя использовать LIKE предикат для запроса отформатированных двоичных данных. Кроме того, LIKE запрос к большому количеству неструктурированных текстовых данных гораздо медленнее, чем эквивалентный полнотекстовый запрос к тем же данным. Запрос LIKE по миллионам строк текстовых данных может занять несколько минут. В отличие от этого, полнотекстовый запрос может занимать всего несколько секунд или меньше по тем же данным, в зависимости от количества возвращаемых строк.

Архитектура полнотекстового поиска

Архитектура полнотекстового поиска состоит из следующих процессов.

  • Процесс SQL Server (sqlservr.exe).

  • Хост-процесс демона фильтра (fdhost.exe).

    Из соображений безопасности фильтры и средства разбиения слов загружаются отдельным процессом, называемым узлом фильтров-демонов. Процесс fdhost.exe создаётся службой запуска FDHOST (MSSQLFDLauncher). Он работает под учётными данными безопасности аккаунта сервиса FDHOST launcher. Следовательно, чтобы работало полнотекстовое индексирование и выполнялись полнотекстовые запросы, должна быть запущена служба FDHOST. Дополнительные сведения о настройке учетной записи службы для этой службы см. в разделе Настройка учетной записи службы для средства запуска управляющей программы фильтра полнотекстового поиска.

Эти два процесса содержат компоненты архитектуры полнотекстового поиска. На следующем рисунке приведены общие сведения об этих компонентах и их отношениях. Описание компонентов приведено после иллюстрации.

Схема архитектуры полнотекстового поиска.

Процесс SQL Server

Процесс ядро СУБД использует следующие компоненты для полнотекстового поиска:

Компонент Описание
Пользовательские таблицы В этих таблицах содержатся данные, по которым осуществляется полнотекстовое индексирование.
Полнотекстовый сборщик Средство сбора полнотекстовых данных работает с потоками полнотекстового сканирования. Он отвечает за планирование и управление населением полнотекстовых индексов, а также для мониторинга полнотекстовых каталогов.
Файлы Тезауруса Эти файлы содержат синонимы искомых терминов. Дополнительные сведения см. в разделе Настройка файлов тезауруса для полнотекстового поиска и управление ими.
Объекты стоп-листа Объекты списка стоп-слов содержат список распространенных слов, которые не полезны для поиска. Для получения дополнительной информации смотрите раздел «Настроить и управлять стоп-вордами и стоп-листами» для Full-Text Search.
Процессор запросов ядро СУБД Обработчик запросов компилирует и выполняет SQL-запросы. Если SQL-запрос включает запрос полнотекстового поиска, то запрос направляется в средство полнотекстового поиска как в процессе компиляции, так и при выполнении. Результат запроса сопоставляется с полнотекстовым индексом.
Полнотекстовый модуль Движок Full-Text в ядро СУБД полностью интегрирован с процессором запросов. Средство полнотекстового поиска компилирует и выполняет полнотекстовые запросы. Как часть выполнения запроса средство полнотекстового поиска может получать входные данные из тезауруса и списка стоп-слов.
Модуль записи индексов (индексатор) Модуль записи индекса строит структуру, используемую для хранения индексированных токенов.
Диспетчер демона фильтрации Диспетчер фильтра отвечает за мониторинг состояния узла фильтра подсистемы полнотекстового поиска.

Фильтрация процесса узла управляющей программы

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

Существуют следующие компоненты узла управляющей программы фильтрации.

Компонент Описание
Обработчик протокола Этот компонент запрашивает данные из памяти для дальнейшей обработки и обращается к данным из пользовательской таблицы в указанной базе данных. Одна из задач — собирать данные из столбцов, индексируемых в полном тексте, и передавать их хосту фильтрующего демона, который применяет фильтрацию и разборку слов по мере необходимости.
Фильтры Некоторые типы данных требуют фильтрации перед тем, как данные в документе могут быть индексированы в полном тексте. К таким типам данных относятся данные в varbinary(max), изображениях или xml-столбцах. Фильтр, используемый для данного документа, зависит от типа этого документа. Например, для документов Microsoft Word (.doc), документов Microsoft Excel (.xls) и XML-документов (.xml) используются разные фильтры. Фильтр извлекает фрагменты текста из документа, удаляет встроенное форматирование и сохраняет текст и, возможно, информацию о его положении. Результатом является поток текстовых данных. Для получения дополнительной информации смотрите раздел «Настройка и управление фильтрами».
Средства разбиения текста на слова и выделения основ слов Средство разбиения на слова — это компонент, зависящий от языка, который определяет границы слов на основе лексических правил данного языка (разбиение на слова). Каждый компонент разбиения слов связан со специфичным для языка компонентом стеммера, который спрягает глаголы и выполняет словоизменительные расширения. Во время индексирования хост управляющей программы фильтра использует модуль разбиения текста на слова и стеммер для выполнения лингвистического анализа текстовых данных из заданного столбца таблицы. Язык, назначенный столбцу таблицы в индексе полнотекстового поиска, определяет, какие средство разбиения текста на слова и средство стемминга используются при индексировании столбца. Дополнительные сведения см. в разделе «Настройка средств разбиения слов и стеммеров и управление ими».

SQL Server 2012 (11.x) устанавливает новую версию средств разбиения слов и стеммеров для английского языка США (LCID 1033) и английского языка Великобритании (LCID 2057). Однако можно переключиться на предыдущую версию этих компонентов, если вы хотите сохранить предыдущее поведение. Дополнительные сведения см. в статье Изменение модуля разбиения слов для американского и британского вариантов английского языка.

Обработка полнотекстового поиска

Полнотекстовый поиск работает на базе средства полнотекстового поиска. Подсистема полнотекстового текста имеет две роли: поддержка индексирования и поддержка запросов.

Процесс полнотекстового индексирования

Когда вы запускаете полнотекстовую популяцию (также известную как обход), движок Full-Text загружает большие массы данных в память и уведомляет хост-фильтр демона. Хост фильтрует и разбивает данные по словам, а также преобразует их в инвертированные списки слов. Индексатор затем извлекает конвертированные данные из списков слов, обрабатывает их для удаления стоп-слов и сохраняет списки слов для партии в один или несколько инвертированных индексов.

При индексации данных, хранящихся в xml, varbinary(max) или столбце изображения, фильтр, реализующий IFilter интерфейс, извлекает текст на основе заданного формата файла для этих данных (например, Microsoft Word). В некоторых случаях компоненты фильтра требуют, чтобы бинарные данные записывались в папку FTData\FilterData , а не передавались напрямую через память.

Одним из этапов обработки собранных текстовых данных является их анализ средством разбиения по словам, которое разделяет текст на отдельные токены, или ключевые слова. Язык, используемый при разметке, задается на уровне столбца или может быть определен компонентом-фильтром по данным типа varbinary(max), imageили xml .

Может быть выполнена дополнительная обработка для удаления стоп-вормов и нормализации токенов до их хранения в полнотекстовом индексном фрагменте.

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

Процесс полнотекстового запроса

Обработчик запросов передает для обработки полнотекстовые части запроса средству полнотекстового поиска. Подсистема полнотекстового поиска выполняет разбиение текста на слова, а также, при необходимости, тезаурусное расширение, стемминг и обработку стоп-слов (шумовых слов). Затем полнотекстовые части запроса представляются в виде операторов SQL, главным образом в виде потоковых табличнозначных функций (STVF). Во время выполнения запроса эти STVF обращаются к инвертированному индексу, чтобы получить корректные результаты. Результаты возвращаются клиенту в данный момент или обрабатываются до возвращения клиенту.

Архитектура полнотекстового индекса

Данные полнотекстовых индексов используются средством полнотекстового поиска для компиляции полнотекстовых запросов, способных быстро находить таблицу с теми или иными словами или словосочетаниями. В полнотекстовом индексе хранятся данные о значимых для поиска словах и их расположении в одном или нескольких столбцах таблицы базы данных. Полнотекстовый индекс — это специальный тип функционального индекса на основе токенов, который создается и поддерживается подсистемой полнотекстового текста для SQL Server. Процесс создания полнотекстового индекса отличается от создания индексов других типов. Вместо построения структуры B-дерева на основе значения, хранящегося в определённой строке, подсистема полнотекстового поиска создаёт инвертированную, многоуровневую, сжатую индексную структуру на основе отдельных токенов индексируемого текста. Размер полнотекстового индекса ограничен только доступными ресурсами памяти компьютера, на котором выполняется экземпляр SQL Server.

Начиная с SQL Server 2008 (10.0.x), полнотекстовые индексы интегрируются с ядро СУБД вместо того, чтобы находиться в файловой системе, как в предыдущих версиях SQL Server. Для новой базы данных полнотекстовый каталог теперь является виртуальным объектом, не входящим ни в одну группу файлов. Это всего лишь логическое понятие, отсылающее к группе полнотекстовых индексов. Однако обратите внимание, что при обновлении базы данных SQL Server 2005 (9.x) для любого полнотекстового каталога с файлами создаётся новая группа файлов. Дополнительные сведения см. в разделе Обновление полнотекстового поиска.

Каждая таблица может содержать только один полный текстовый индекс. Для создания полнотекстового индекса в таблице таблица должна иметь один уникальный столбец без нуля. Можно построить полнотекстовый индекс на столбцах типа char, varchar, nchar, nvarchar, text, ntext, image, xml и varbinary(max). Когда вы создаёте полнотекстовый индекс на столбце с типом данных varbinary(max),image или xml, необходимо указать столбец типа. Столбец типа — это столбец таблицы, в котором хранится расширение файла (.doc, .pdfи .xlsт. д.) документа в каждой строке.

Структура полнотекстового индекса

Хорошее понимание структуры полнотекстового индекса помогает понять, как работает полнотекстовый модуль. В этой статье используется следующий фрагмент Document таблицы в AdventureWorks2025 качестве примера таблицы. В этом фрагменте показаны только два столбца — столбец DocumentID и столбец Title — а также три строки из таблицы.

Для этого примера предположим, что на столбце Title создан полный индекс текста.

Идентификатор документа Заголовок
1 Crank Arm and Tire Maintenance
2 Front Reflector Bracket and Reflector Assembly 3
3 Front Reflector Bracket Installation

Например, в следующей таблице, в которой показан фрагмент 1, отображается содержимое полнотекстового индекса, созданного в Title столбце Document таблицы. Полнотекстовые индексы содержат больше данных, чем представлено в этой таблице. Таблица является логическим представлением полнотекстового индекса, она предоставляется только с целью демонстрации. Строки хранятся в сжатом формате для оптимизации использования диска.

Данные инвертированы относительно исходных документов. Инверсия происходит, поскольку ключевые слова сопоставлены с идентификаторами документов. По этой причине полнотекстовый индекс часто называют инвертированным индексом.

Обратите внимание, что ключевое слово and удаляется из полнотекстового индекса, так как and это стоп-слово. Удаление стоп-слов из полнотекстового индекса может привести к значительной экономии места на диске, что повышает производительность запросов. Дополнительные сведения о стоп-словах см. в статье «Настройка стоп-слов и списков стоп-слов для полнотекстового поиска».

Фрагмент 1

Ключевое слово ColId DocId Вхождение
Crank 1 1 1
Arm 1 1 2
Tire 1 1 4
Maintenance 1 1 5
Front 1 2 1
Front 1 3 1
Reflector 1 2 2
Reflector 1 2 5
Reflector 1 3 2
Bracket 1 2 3
Bracket 1 3 3
Assembly 1 2 6
3 1 2 7
Installation 1 3 4

Столбец Keyword содержит представление одного маркера, извлеченного во время индексирования. Средства разбиения на слова определяют, что составляет токен.

Столбец ColId содержит значение, которое соответствует определённому столбцу, включённому в полнотекстовый индекс.

Столбец DocId содержит значения для целого числа 8-байтов, которое сопоставляется с определенным значением полнотекстового ключа в полнотекстовой индексированной таблице. Это сопоставление необходимо, если полнотекстовый ключ не является целым типом данных. В таких случаях сопоставления между значениями полнотекстового ключа и значениями DocId поддерживаются в отдельной таблице, называемой таблицей DocId Mapping. Чтобы выполнить запрос к этим сопоставлениям, используйте системную хранимую процедуру sp_fulltext_keymappings. Чтобы удовлетворить условие поиска, DocId значения из предыдущей таблицы необходимо объединить с DocId таблицей сопоставления, чтобы получить строки из базовой таблицы, запрашиваемой. Если значение полнотекстового ключа базовой таблицы имеет целочисленный тип, это значение напрямую используется как DocId, и сопоставление не требуется. Следовательно, использование целочисленных значений полнотекстового ключа может оптимизировать выполнение полнотекстовых запросов.

Столбец Occurrence содержит целочисленное значение. Для каждого DocId значения существует список значений появления, соответствующих относительным смещениям по словам конкретного ключевого слова внутри этого DocId. С помощью значений частотности удобно определять фразовое или близкое совпадение; например, для фраз значения частотности находятся рядом. Они также полезны для вычисления баллов релевантности. Например, количество появления ключевого слова в a DocId может использоваться при подсчёте оценок.

Фрагменты полнотекстового индекса

Логический полнотекстовый индекс обычно разбивается по нескольким внутренним таблицам. Каждая из внутренних таблиц называется фрагментом полнотекстового индекса. Некоторые из данных фрагментов могут содержать более свежие данные. Например, если пользователь обновляет следующую строку, у которой значение DocId равно 3, и для таблицы автоматически отслеживаются изменения, создаётся новый фрагмент.

Идентификатор документа Заголовок
3 Rear Reflector

В следующем примере, на котором показан фрагмент 2, фрагмент содержит более поздние данные о DocId 3 по сравнению с фрагментом 1. Таким образом, когда пользователь выполняет запрос для Rear Reflector, используются данные из фрагмента 2 для DocId 3. Каждый из фрагментов имеет отметку времени создания, которую можно использовать в запросах с помощью представления каталога sys.fulltext_index_fragments .

Фрагмент 2

Ключевое слово ColId DocId Occ
Rear 1 3 1
Reflector 1 3 2

Как можно увидеть во фрагменте 2, полнотекстовым запросам необходимо осуществить внутреннее обращение к каждому фрагменту. Более старые записи не учитываются. Следовательно, наличие слишком большого количества полнотекстовых фрагментов индекса в полнотекстовом индексе может привести к существенному уменьшению производительности запросов. Чтобы уменьшить количество фрагментов, реорганизуйте полнотекстовый каталог, используя REORGANIZE опцию ALTER FULLTEXT CATALOG оператора Transact-SQL. Данная инструкция выполняет слияние в единый файл, объединяя все фрагменты в единый большой фрагмент, и удаляет все устаревшие записи из полнотекстового индекса.

После выполнения реорганизации в образце индекса будут содержаться следующие строки.

Ключевое слово ColId DocId Occ
Crank 1 1 1
Arm 1 1 2
Tire 1 1 4
Maintenance 1 1 5
Front 1 2 1
Rear 1 3 1
Reflector 1 2 2
Reflector 1 2 5
Reflector 1 3 2
Bracket 1 2 3
Assembly 1 2 6
3 1 2 7

Различия между полнотекстовых индексами и обычными индексами SQL Server

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

Full-Text Лингвистические компоненты поиска и поддержка языка

Полнотекстовый поиск поддерживает более 50 различных языков, таких как английский, испанский, китайский, японский, арабский, бенгальский и хинди. Полный список поддерживаемых языков полнотекстового поиска см. в sys.fulltext_languages. Каждый из столбцов, содержащихся в индексе полного текста, связан с идентификатором Microsoft Windows локации (LCID), который соответствует языку, поддерживаемому полнотекстовым поиском. Например, LCID 1033 соответствует американскому английскому, а LCID 2057 — британскому. Для каждого поддерживаемого полнотекстового языка ядро СУБД предоставляет лингвистические компоненты, поддерживающие индексацию и запросы к полнотекстовым данным, хранящихся на этом языке.

Компоненты, относящиеся к языку, включают следующие элементы:

Компонент Описание
Средства разбиения текста на слова и выделения основ слов Модуль сегментации слов определяет границы слов на основе лексических правил заданного языка (разбиение слов). Каждое средство разбиения по словам связано с парадигматическим модулем, который спрягает глаголы этого языка и т. п. Для получения дополнительной информации см. раздел «Настройка средств разбиения слов и стеммеров и управление ими».
Стоп-листы Предоставляется системный список стоп-слов, содержащий базовый набор стоп-слов (также известный как шумовые слова). Стоп-слово — это слово, которое не влияет на результаты поиска и игнорируется при полнотекстовом поиске. Например, в английской локали такие слова, как a, and, is и the, считаются стоп-словами. Как правило, необходимо настроить один или несколько файлов тезауруса и стоп-списков. Для получения дополнительной информации смотрите раздел «Настроить и управлять стоп-вордами и стоп-листами» для Full-Text Search.
Файлы Тезауруса ядро СУБД также устанавливает файл тезауруса для каждого полнотекстового языка и глобальный файл тезауруса. Установленные файлы тезауруса пусты, но их можно изменить, чтобы определить синонимы для определенного языка или бизнес-сценария. Подготовив тезаурус, ориентированный на пользовательские полнотекстовые данные, можно эффективно расширить область полнотекстовых запросов к этим данным. Дополнительные сведения см. в разделе Настройка файлов тезауруса для полнотекстового поиска и управление ими.
Фильтры (IFilters) Индексирование документа в столбце типа данных varbinary(max), imageили xml требует наличия фильтра для выполнения дополнительной обработки. Фильтр должен соответствовать типу документа (.doc, , .pdfи .xls.xmlт. д.). Для получения дополнительной информации смотрите раздел «Настройка и управление фильтрами».

Связанный контент

  • Last updated on