SQL Server 2008 - оценка битовых параметров меняет план выполнения - PullRequest
0 голосов
/ 23 марта 2010

Я работал над переносом некоторых наших данных из Microsoft SQL Server 2000 в 2008. Среди обычных икота и прочего я столкнулся с чем-то странным. Ниже приведен SQL-запрос, который очень быстро возвращается до 2000, но занимает менее 20 минут до 2008 года. Я немного прочитал об обновлении SQL-сервера и прошел обычные пути проверки индексов, статистики и т. Д., Прежде чем пришел к выводу следующий оператор, найденный в предложении WHERE, вызывает резкое изменение плана выполнения шагов, следующих за этим оператором:

  And (
    @bOnlyUnmatched = 0 -- offending line
    Or Not Exists(

Операторы SQL и планы выполнения связаны ниже.

Сотрудник смог переписать часть предложения WHERE с помощью оператора CASE, который, кажется, «обманывает» оптимизатор при использовании лучшего плана выполнения. Версия с оператором CASE также содержится в связанном архиве.

Мне бы хотелось узнать, есть ли у кого-нибудь объяснение, почему это происходит, и может ли быть более элегантное решение, чем использование оператора CASE. Хотя мы можем обойти эту конкретную проблему, я хотел бы иметь более широкое понимание того, что происходит, чтобы гарантировать, что остальная часть миграции будет максимально безболезненной.

Zip-файл с инструкциями SQL и планами выполнения XML

Заранее спасибо!

1 Ответ

0 голосов
/ 27 мая 2010

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

У оптимизатора запросов гораздо больше свободы в SQL Server> = 2005. Решение CASE, вероятно, является наилучшим маршрутом.

...