Има няколко начина да осигурите повторно компилиране на съхранена процедура:
- използване на
WITH RECOMPILE, - като съхранената процедура стане динамична (помислете за
exec()) - маркиране на процедурата за повторно компилиране с
sp_recompile. - промяна на схемата, на която разчита кеширан план за заявка
- извикване на
DBCC FREEPROCCACHE - На ниво заявка отделен израз в рамките на процедура може да бъде прекомпилиран с подсказката за заявка RECOMPILE (SQL 2008).
Фактори при повторно компилиране
Освен изброените по-горе трудни фактори, какво причинява повторно компилиране на съхранена процедура? Е, много неща. Някои от тях са вплетени в списъка по-горе, но искам да ги представя отново b/c, може да не е очевидно.
- Вмъкване или изтриване на много данни (плътността на данните в индексите и таблиците често контролира плановете за заявки)
- Преизграждане на индекси (промяна в базовите обекти)
- Създаване/изтриване на временни таблици (отново, основни DML промени).
- планът за заявки остаря (мисля, че не е използван наскоро и sql иска да изчисти използването на паметта)
Това в никакъв случай не е изчерпателен списък. Оптимизаторът на заявки се развива и изненадва, независимо колко дълго сте използвали SQL Server. Но ето някои ресурси, които могат да бъдат полезни:
- Отстраняване на неизправности при повторно компилиране на съхранена процедура (старо, но добро)
- Попълване на съхранени процедури
- Оптимизиране на съхранените процедури на SQL Server за избягване на повторно компилиране
- Кеширане и повторно използване на план за изпълнение (задължително за четене)
НО ПОЧАКАЙТЕ - ИМА ОЩЕ!
С това казано, презумпцията във вашия въпрос е, че повторното компилиране винаги е лошо за производителността. Всъщност често повторната комплиация е добра.
И така, кога бихте искали да се прекомпилира? Нека да разгледаме един пример за процедура, която търси по фамилия. Съхранените процедури извършват „насочване на параметри
' което е благословия (ако работи за вас) и проклятие (ако работи срещу вас). Първо преминете някой търси на Zebr% за zerbrowski. Индексът на фамилията осъзнава, че това е много специфично и ще върне, да речем, 3 реда от милион -- така че е изграден един план за изпълнение. С процедурата, компилирана за резултат с нисък ред, следващото търсене е за S% . Е, S е вашето най-често срещано име и съвпада с 93 543 реда от 1 милион.
