Производительность SQL Server FTS после добавления множества записей

Question

У нас есть веб-приложение, которое позволяет клиентам управлять большими списками имен. Для поиска в этих списках мы используем FTS для SQL Server 2008, которая обычно работает хорошо. Наш крупнейший клиент имеет 900 000 имен и имеет время поиска менее секунды.

Однако для другого нового клиента я недавно импортировал 150 000 имен, и производительность ужасна (как, например, изнурительно ужасно для сервера). Я проверил полнотекстовый индексатор, и он утверждает, что недавно завершил сканирование.

Глядя на планы выполнения, я замечаю, что в быстром случае (для более крупного клиента) SQL Server сначала выполняет FTS, а затем выполняет поиск индекса по результату. Для более нового клиента сначала выполняется поиск по индексу (по-видимому, 150 000 раз для новых записей), а затем FTS.

Итак, я попробовал подсказку WITH (INDEX (MyFullTextIndex)), но SQL Server говорит, что индекс не существует. Очевидно, он не считает эти индексы FTS «реальными». Как я могу заставить SQL Server всегда сначала использовать FTS?

ОБНОВЛЕНИЕ: я попытался восстановить статистику, но безрезультатно. Те же проблемы с производительностью.

Вот планы выполнения:

БЫСТРАЯ производительность: http://frameaction.com/LLExecutionPlan01.sqlplan

МЕДЛЕННАЯ производительность: http://frameaction.com/LLExecutionPlan18.sqlplan

Answer 1

Я попытался добавить подсказку «OPTIMIZE VALUE FOR UNKNOWN» в конце моего запроса (мне также пришлось добавить фиктивную переменную в запрос, чтобы в подсказке было что-то для ссылки). Пока, похоже, работает хорошо. Я немного нервничаю по поводу добавления подсказок, и поэтому все еще ищу лучшее решение, но пока это работает.

Answer 2

Индекс FTS - это черный ящик, к которому сервер sql может присоединиться только в своем наборе результатов, он всегда просматривает всю таблицу независимо от каких-либо предложений where или внутренних объединений. Один из способов повысить производительность поиска FT - это выполнить объединение и любые предложения, не основанные на параметрах where, в пределах представления, связанного со схемой, и поиск полнотекстового индекса в этом представлении.

Answer 3

Я никогда не использовал службу FTS в SQL Server, но, как сказал первый автор, я обнаружил, что при загрузке хранилищ данных или отчетов баз данных некоторые запросы, которые выполнялись нормально, выполнялись очень медленно после загрузки большого объема данных. Запуск sp_updatestats после каждой загрузки решал проблему (даже если опция базы данных статистики автообновления отмечена (это по умолчанию).

Answer 4

Не уверен, что это поможет, но вы можете попробовать использовать CONTAINSTABLE - который позволяет вам изменить порядок соединения.

SELECT customer_id FROM клиентов ГДЕ СОДЕРЖИТ (имя клиента, 'Foobar')

Становится

ВЫБРАТЬ customer_id ОТ Клиенты AS FTTABLE INNER JOIN CONTAINSTABLE (Клиенты, имя клиента, 'Foobar') FTINDEX ON FTINDEX. [Key] = FTTABLE.customer_id

Answer 5

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

Затем убедитесь, что ваша статистика обновлена. Информация об обновлении вашей статистики для каждой таблицы находится здесь в Books Online:

http://msdn.microsoft.com/en-us/library/ms187348.aspx

Я бы обновил с fullscan, чтобы убедиться, что вы получаете хорошие данные.

Наконец, если ни один из этих способов не работает, запустите запрос в SQL Server Management Studio, но используйте параметр «Включить фактический план запроса». Затем щелкните правой кнопкой мыши в любом месте плана запроса и выберите «Сохранить как XML». Разместите два разных плана запросов где-нибудь в Интернете, и мы посмотрим, в чем разница и почему.