Проблемы
При заполнении табличной переменной большого количества строк, а затем объединения ее с другими таблицами оптимизатор запросов может выбрать неэффективный план запроса, что может привести к снижению производительности запроса.
Решение
После того как вы установите это исправление, вы можете включить флаг трассировки 2453, чтобы разрешить повторное компиляцию переменной таблицы при изменении достаточного количества строк. Это может позволить оптимизатору запросов выбрать более эффективный план. Эта проблема впервые устранена в указанных ниже накопительных обновлениях и пакетах обновления для SQL Server.
Накопительное обновление 3 для SQL Server 2014 /en-us/help/2984923
Все новые накопительные обновления для SQL Server содержат все исправления и все исправления для системы безопасности, которые были включены в предыдущий накопительный пакет обновления. Ознакомьтесь с самыми последними накопительными обновлениями для SQL Server.
Пакеты обновления являются накопительными. Каждый новый пакет обновления включает все исправления из предыдущих пакетов обновления вместе с новыми исправлениями. Наши рекомендации относятся к установке последнего пакета обновления и последнего накопительного обновления для этого пакета обновления. Перед установкой последнего пакета обновления вам не нужно устанавливать предыдущий пакет обновления. Чтобы найти дополнительные сведения о последнем пакете обновления и последнем накопительном обновлении, воспользуйтесь таблицей 1 в следующей статье:
Определение версии, выпуска и уровня обновления SQL Server и его компонентов
Дополнительная информация
При использовании табличной переменной в пакете или процедуре запрос компилируется и оптимизируется для первоначального пустого состояния переменной table. Если эта табличная переменная заполнена большим количеством строк во время выполнения, предварительно скомпилированный план запроса может быть неоптимальным. Например, запрос может присоединиться к табличной переменной с вложенным циклом, так как он обычно более эффективен для небольшого количества строк. Этот план запроса может быть неэффективным, если переменная table содержит миллионы строк. При использовании такого условия может быть предпочтительнее хэш-соединение. Для получения нового плана запроса его необходимо перекомпилировать. Тем не менее, в отличие от других пользовательских и временных таблиц, изменение количества строк в табличной переменной не вызывает повторную компиляцию запроса. Как правило, вы можете обойти эту функцию с параметром (ПЕРЕКОМПИЛИРУЙТЕ), в которой есть затраты на накладные расходы. Флаг трассировки 2453 позволяет получить преимущество при повторной компиляции запроса без параметра (RECOMPILE). Этот флаг трассировки отличается от OPTION (ПЕРЕКОМПИЛИРУЙТЕ) в двух основных аспектах. (1) он использует то же пороговое значение количества строк, что и другие таблицы. Запрос не требуется компилировать для каждого выполнения, в отличие от варианта (ПЕРЕКОМПИЛИРУЙТЕ). Это вызовет перекомпиляцию только в том случае, если изменение количества строк превышает предопределенный порог. (2) параметр (RECOMPILE) заставляет запрос считывать параметры и оптимизировать запрос для них. Этот флаг трассировки не является принудительным просмотром параметров.Примечание . Этот флаг трассировки должен быть включен во время выполнения. Этот флаг трассировки нельзя использовать с QUERYTRACEON. Этот флаг трассировки следует использовать с осторожностью, так как он может увеличить количество повторных компиляций запросов, что может привести к более выгодным затратам от улучшенной оптимизации запросов.
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".
