Er zijn tijden dat het gebruik van OPTION(RECOMPILE) klinkt logisch. In mijn ervaring is dit de enige keer dat dit een haalbare optie is wanneer u dynamische SQL gebruikt. Voordat je gaat onderzoeken of dit in jouw situatie zinvol is, zou ik je aanraden om je statistieken opnieuw op te bouwen. Dit kan worden gedaan door het volgende uit te voeren:
EXEC sp_updatestats
En dan je uitvoeringsplan opnieuw maken. Dit zorgt ervoor dat wanneer uw uitvoeringsplan wordt gemaakt, het de nieuwste informatie gebruikt.
OPTION(RECOMPILE) toevoegen herbouwt het uitvoeringsplan elke keer dat uw query wordt uitgevoerd. Ik heb nog nooit gehoord dat dit wordt beschreven als creates a new lookup strategy maar misschien gebruiken we gewoon verschillende termen voor hetzelfde.
Wanneer een opgeslagen procedure wordt gemaakt (ik vermoed dat u ad-hoc sql vanuit .NET aanroept, maar als u een geparametriseerde query gebruikt, wordt dit uiteindelijk een opgeslagen proc-aanroep) probeert SQL Server het meest effectieve uitvoeringsplan voor deze query te bepalen op basis van de gegevens in uw database en de doorgegeven parameters (parameter sniffing), en slaat dit plan vervolgens op in de cache. Dit betekent dat als u de query maakt met 10 records in uw database en deze vervolgens uitvoert wanneer er 100.000.000 records zijn, het uitvoeringsplan in de cache mogelijk niet langer het meest effectief is.
Samengevat - ik zie geen reden waarom OPTION(RECOMPILE) zou hier een voordeel zijn. Ik vermoed dat je gewoon je statistieken en je uitvoeringsplan moet bijwerken. Het opnieuw opbouwen van statistieken kan een essentieel onderdeel zijn van DBA-werk, afhankelijk van uw situatie. Als je nog steeds problemen hebt nadat je je statistieken hebt bijgewerkt, raad ik aan om beide uitvoeringsplannen te posten.
En om uw vraag te beantwoorden:ja, ik zou zeggen dat het hoogst ongebruikelijk is dat uw beste optie het uitvoeringsplan opnieuw compileert telkens wanneer u de query uitvoert.