Симптоми
Когато попълните променлива на таблица с много редове и след това я съедините с други таблици, оптимизаторът на заявките може да избере неефективен план за заявката, което може да доведе до бавна производителност на заявките.
Решение
След като приложите тази гореща корекция, можете да включите проследяване на флаг 2453, за да позволите променлива на таблица да активира повторно съставяне, когато е променен достатъчен брой редове. Това може да позволи на оптимизатора на заявките да избере по-ефективен план.
Проблемът е отстранен за първи път в следната кумулативна актуализация и/или сервизни пакети за SQL Server.
Сборна актуализация 3 за SQL Server 2014 г. /en-us/help/2984923
За кумулативните актуализации за SQL Server
Всяка нова кумулативна актуализация за SQL Server съдържа всички актуални поправки и корекции на защитата, които са били включени в предишната кумулативна актуализация. Прегледайте последните кумулативни актуализации за SQL Server:
Service pack 2 за SQL Server 2012
За сервизните пакети за SQL Server
Сервизните пакети са кумулативни. Всеки нов сервизен пакет съдържа всички корекции, които са в предишните сервизни пакети, заедно с всички нови корекции. Нашата препоръка е да се приложи най-новият сервизен пакет и най-новата кумулативна актуализация за този сервизен пакет. Не е необходимо да инсталирате предишен сервизен пакет, преди да инсталирате най-новия сервизен пакет. Използвайте таблица 1 в следващата статия, за да намерите повече информация относно най-новия сервизен пакет и най-новата кумулативна актуализация:
Как да определите версията, изданието и нивото на актуализация на SQL Server и неговите компоненти
Повече информация
Когато използвате променлива на таблица в партида или процедура, заявката се компилира и оптимизира за началното празно състояние на променливата на таблица. Ако тази променлива на таблицата се попълва с много редове по време на изпълнение, предварително съставеният план за заявка може вече да не е оптимален. Например заявката може да съединява променлива на таблица с вложен цикъл, тъй като тя обикновено е по-ефективна за малък брой редове. Този план за заявка може да бъде неефективен, ако променливата на таблицата има милиони редове. При такива условия хеширане може да се окаже по-добър избор. За да получите нов план за заявка, той трябва да се състави отново. За разлика от други потребителски или временни таблици обаче, промяната в броя редове в променливата на таблицата не задейства повторно съставяне на заявка. Обикновено можете да заобиколите този проблем с функцията OPTION (RECOMPILE), която има свои собствени режийни разходи.
Флагът за проследяване 2453 позволява ползата от повторно съставяне на заявки без OPTION (RECOMPILE). Този флаг за проследяване се различава от OPTION (RECOMPILE) в два основни аспекта.
(1) Използва същия праг за брой редове като другите таблици. Заявката не трябва да се компилира за всяко изпълнение, за разлика от OPTION (RECOMPILE). Това ще задейства повторно съставяне само когато промяната в броя на редовете надхвърли предварително зададения праг.
(2) OPTION (RECOMPILE) принуждава заявката да надниква в параметрите и да оптимизира заявката за тях. Този флаг за проследяване не налага надникване в параметрите.
Обърнете внимание, че този флаг за проследяване трябва да е включен по време на изпълнение. Не можете да използвате този флаг за проследяване с QUERYTRACEON. Този флаг за проследяване трябва да се използва с повишено внимание, защото може да увеличи броя на повторно съставяне на заявките, което може да струва повече от спестявания от по-добро оптимизиране на заявките.
Състояние
Microsoft потвърждава, че това е проблем в продуктите на Microsoft, които са изброени в раздела „Важи за“.