Производительность запросов объединенного индекса по сравнению с несколькими отдельными индексами по сравнению с полнотекстовым индексом

Question

Справочная информация: У меня есть таблица с 5 миллионами записей адресов, которые я хотел бы найти в различных полях (имя клиента, имя контакта, почтовый индекс, город, телефон, ...), до 8 полей. Данные довольно стабильны, максимум 50 изменений в день, поэтому доступ только для чтения.

Пользователь не должен сообщать мне заранее, что он ищет, и я также хочу поддержку комбинированного поиска (AND-конкатенация поисковых терминов). Например, «lincoln + lond» должен искать все записи, содержащие оба термина поиска в любом из полей поиска, а также записи, начинающиеся с любого из терминов (например, «Лондон» в этом примере).

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

1. Создать объединенный индекс из всех запрашиваемых столбцов (потребуется 2 из них, поскольку достигнут предел индекса в 900 байт)
2. Поместить отдельные индексы в каждый из запрашиваемых столбцов
3. Создание полнотекстового индекса для столбцов с запросом и использование полнотекстового запроса

Я отбрасываю пункт 1, так как он, похоже, не имеет никаких преимуществ (использование индекса будет ограничено, и не будет никакого «поиска по индексу», поскольку не все поля умещаются в один индекс).

Вопрос: Теперь, я должен использовать вариант несколько отдельных индексов или мне следует использовать полнотекстовый индекс ? Есть ли какой-либо другой способ для достижения вышеупомянутой функциональности?

Answer 1

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

Answer 2

Изначально я собирался предложить перейти на FTS , так как он имеет много сильных характеристик производительности. Особенно, когда вы имеете дело с различными запросами. (например, x и y. x около y и т. д.).

Но прежде чем я начну рассказывать про профессионалов FTS, я просто проверил версию вашего сервера -> sql2000.

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

Мы используем Sql2008 и ... это круто.

О, кстати. Знаете ли вы, что Sql2008 (бесплатная версия) имеет FTS в нем? Можно ли обновить?

Переход с sql2000 -> sql2008 очень стоит, если можно.

Но да, придерживайтесь своего М.С.И. опция.

Answer 3

Чтобы ответить на мой вопрос:

Я выбрал опцию «несколько отдельных индексов». Я закончил иметь индекс для каждого из запрашиваемых столбцов, каждый индекс содержит только сам столбец. Поиск работает очень хорошо, время отклика не превышает секунды. Иногда это занимает до 2-3 секунд, но я приписываю его своему серверу баз данных (ноутбук нескольких лет с оперативной памятью 3 ГБ и медленным диском).

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

Answer 4

Я согласен с Grauenwolf и хотел бы добавить примечание об индексах. Имейте в виду, что если вы используете синтаксис, подобный следующему:

SELECT field1, field2, field3
FROM table
WHERE field1 LIKE '%value%

Тогда при поиске по field1 индекс все равно не будет использоваться, и вам придется прибегнуть к полнотекстовому индексу. Для полноты приведенный выше синтаксис возвращает все строки, где field1 содержит значение (необязательно в начале). Если вам нужно искать «содержит», полнотекстовый индекс, вероятно, более уместен.