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