SQL Server 2005 FreeText () Проблема.

Question

У меня есть запрос с присоединичными таблицами около 6-7 и FreeText () Predicate на 6 столбцов базовой таблицы в то, где.

Теперь этот запрос работал нормально (менее чем за 2 секунды) в течение последнего года и практически оставался без изменений (я пробовал старые версии, и проблема сохраняется)

Поэтому сегодня вдруг тот же запрос занимает около 1-1,5 минут.

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

Я временно переключил запрос на использование LIKE Вместо того, пока я не поймую это (который сейчас занимает около 6 секунд).

Когда я смотрю на запрос в анализаторе производительности запросов, когда сравниваю «Freetext'Query с «подобным» запросом, в 350 раз больше читается (4921261 против 13943) и 20 раз (38937 против 1938) Использование процессора последнего.

Итак, это действительно «эффект», который заставляет его быть таким медленным.

У кого-нибудь есть идеи по тому, что может быть причиной? Или дальнейшие тесты, которые я мог сделать?

Редактировать

Ну, я просто снова провел запрос, чтобы получить план исполнения, и теперь он снова занимает 2-5 секунд, без каких-либо изменений, сделанных ему, хотя проблема все еще существовала вчера. И это не было связано с любыми внешними факторами, поскольку я остановил все приложения, доступ к базе данных, когда я впервые проверил эту проблему в прошлый четверг, поэтому он не был связан с другими нагрузками.

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

План запроса

хорошо, вот полный запрос

Возможно, мне придется объяснить, что именно это делает. По сути, это получает результаты поиска для объявлений на работу, где есть два типа рекламы, премиум и нормальные. Результаты страгают до 25 результатов на страницу, 10 премиум-класса вверху и 15 нормальных после этого, если достаточно.

Таким образом, есть два внутренних запроса, которые выбирают как необходимо множество премиум / обычных, по мере необходимости (например, на странице 10 выбирает верхние 100 премиум-класса и топ-150 нормальных), то эти два запроса чередуются с помощью команды row_number () и некоторые математики Отказ Затем комбинация заказывается Rownumber, а запрос возвращается. Ну, он используется в другом месте, чтобы просто получить 25 объявлений, необходимых для текущей страницы.

Ох, и весь этот запрос построен в огромном устаревшем файле ColdFusion, и, поскольку он работает нормально, я не осмелился до сих пор Thouching / меняя большие порции ... Никогда не касайтесь беговой системы и так далее;) Просто маленькие вещи, как меняется биты центрального пункта, где.

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

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

Answer 1

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

Как вы находите производительность, если вы сломаете его на 2 шага?

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

(NB: вы можете попробовать это присоединиться к и без OPTION(RECOMPILE) Пока глядя на планы запроса для (а) бесплатного текстового поискового запроса, который возвращает множество результатов (B), который возвращает только горсть результатов.)

Редактировать Трудно уточнить именно в отсутствие оскорбительного запроса, но то, что я имею в виду, вместо того, чтобы делать

SELECT <col-list>
FROM --Some 6 table Join
WHERE FREETEXT(...);

Как это работает?

DECLARE @Table TABLE
(
<pk-col-list>
)
INSERT INTO @Table
SELECT PK
FROM YourTable
WHERE FREETEXT(...)

SELECT <col-list>
FROM --Some 6 table Join including onto @Table
OPTION(RECOMPILE)

Answer 2

Обычно, когда у нас есть этот вопрос, это из-за фрагментации таблицы и устаревшей статистики по вопросам индексов.

В следующий раз попробуйте exec SP_UPDATESTATS. После восстановления / реиндекса.

Видеть Использование статистики для улучшения производительности запроса для получения дополнительной информации.