Има случаи, когато се използва OPTION(RECOMPILE) има смисъл. Според моя опит единственият път, когато това е жизнеспособна опция, е, когато използвате динамичен SQL. Преди да проучите дали това има смисъл във вашата ситуация, бих препоръчал да възстановите статистиката си. Това може да стане, като изпълните следното:
EXEC sp_updatestats
И след това пресъздаване на вашия план за изпълнение. Това ще гарантира, че когато вашият план за изпълнение е създаден, той ще използва най-новата информация.
Добавяне на OPTION(RECOMPILE) възстановява плана за изпълнение всеки път, когато вашата заявка се изпълнява. Никога не съм чувал това, описано като creates a new lookup strategy но може би просто използваме различни термини за едно и също нещо.
Когато се създаде съхранена процедура (подозирам, че извиквате ad-hoc sql от .NET, но ако използвате параметризирана заявка, тогава това се оказва съхранено proc извикване) SQL Server се опитва да определи най-ефективния план за изпълнение за тази заявка въз основа на данните във вашата база данни и предадените параметри (снифиране на параметри) и след това кешира този план. Това означава, че ако създадете заявката, където има 10 записа във вашата база данни и след това я изпълните, когато има 100 000 000 записа, кешираният план за изпълнение може вече да не е най-ефективен.
В обобщение - не виждам причина OPTION(RECOMPILE) би било от полза тук. Подозирам, че просто трябва да актуализирате статистиката и плана си за изпълнение. Възстановяването на статистически данни може да бъде съществена част от работата на DBA в зависимост от вашата ситуация. Ако все още имате проблеми след актуализиране на статистиката си, предлагам да публикувате и двата плана за изпълнение.
И за да отговоря на въпроса ви – да, бих казал, че е много необичайно най-добрият ви вариант да прекомпилирате плана за изпълнение всеки път, когато изпълнявате заявката.
