Сокращение количества результатов, возвращаемых из полнотекстового запроса

Question

Я использую ключевое слово CONTAINS для поиска в полнотекстовом каталоге SQL-Server.Таблица, которую я запрашиваю, содержит (среди других столбцов) текстовый столбец с полнотекстовой индексацией и столбец "Added_date", который представляет дату добавления строки (и с нормальным индексом).

Таблица содержит около 7 миллионов строк.Отдельные запросы в полнотекстовом каталоге могут возвращать ~ 1 млн строк.Я хочу использовать столбец "add_date", чтобы уменьшить количество строк, возвращаемых запросом.

Проблема заключается в том, что при добавлении условия "add_date" в плане выполнения я вижу, что БД будет запрашиватьтаблица дважды: один раз для полнотекстового каталога (называемого «удаленное сканирование» в плане выполнения) и один раз для условия даты.Это вынуждает БД объединять результаты обеих частей запроса, поэтому повышение производительности не достигается.

Существует ли способ заставить SQL Server выполнять полнотекстовый запрос только тех строк, которые остаются после условия даты

РЕДАКТИРОВАТЬ: запрос выглядит как

SELECT reason, added_date FROM reasons_table WHERE CONTAINS(reason, 'a_reason') AND added_date > getdate()-5

Answer 1

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

Вот некоторые идеи, которые приходят в голову, когда я читаю эту статью:

1. Внедрите критерии фильтрации в ваш текст
   • Проверьте в статье маркер «Рассматривать встраивание условий фильтрации в качестве ключевых слов в индексированный текст».
   • По сути, это говорит о том, что вы можете рассмотреть возможность размещения своей даты в виде легко определяемой строки в тексте.Например, "«Что-то, что вы можете вырезать перед обработкой текста.
   • Возможно, не подходит для диапазонов, хотя обходной путь для этого - более грубый термин фильтра. Т.е. вместо DateAdded: YYYYMMDD используйте WeekAdded: YYYYWW, тогда вывы тратите на FTS 7-14 дней, и ваш предикат added_date может еще больше сузить его.
   • Возможно, он перестанет быть полезным задолго до 100 поисковых терминов.
   • Добавление критериев фильтрации означает выполнениеобновление, чтобы добавить его ко всем 7m + записям
   • В противном случае, это кажется наиболее близким по духу к тому, что вы ищете
2. Две таблицы - горизонтальный раздел
   • Если вы в основном оглядываетесь назад только на несколько дней, вы можете попытаться просто сохранить вторую таблицу с FTS только с последними n днями записей.
   • Может быть PITA для ведения.
3. Две таблицы - вертикальное разбиение
   • Разделите вашу таблицу на 1 со значениями, по которым вы собираетесь фильтровать в SQL, а другую - с текстом FTS. Затем используйте CONTAINSTСПОСОБНОСТЬ собрать их вместе.
   • Вы все еще делаете 2 попадания в таблицу.Однако, одно преимущество заключается в том, что ваша уменьшенная таблица будет более узкой, с большим количеством записей на страницу и меньшим количеством операций ввода-вывода.
   • По общему признанию, это улучшение может даже не быть заметным.И при всем этом индекс покрытия может быть таким же хорошим.
4. Живите с ним
   • У вас есть показатели производительности, чтобы показать, что это двойное чтение приводит кбольшая потеря в производительности?Предполагая, что ваш PK составляет <10 байт, и у вас есть индекс в ваших искомых полях, я думаю, что вам понадобится отобрать 20k + отфильтрованных записей, чтобы заметить дополнительное чтение?Есть ли что-нибудь из этого для вашей конкретной ситуации? </p>