Ci sono volte in cui usando OPTION(RECOMPILE) ha senso. Nella mia esperienza, l'unica volta che questa è un'opzione praticabile è quando si utilizza SQL dinamico. Prima di esplorare se questo ha senso nella tua situazione, consiglierei di ricostruire le tue statistiche. Questo può essere fatto eseguendo quanto segue:
EXEC sp_updatestats
E poi ricreare il tuo piano di esecuzione. Ciò garantirà che quando verrà creato il piano di esecuzione utilizzerà le informazioni più recenti.
Aggiunta di OPTION(RECOMPILE) ricostruisce il piano di esecuzione ogni volta che viene eseguita la query. Non ho mai sentito che descritto come creates a new lookup strategy ma forse stiamo solo usando termini diversi per la stessa cosa.
Quando viene creata una stored procedure (sospetto che tu stia chiamando sql ad-hoc da .NET ma se stai utilizzando una query con parametri, questa finisce per essere una chiamata stored proc) SQL Server tenta di determinare il piano di esecuzione più efficace per questa query in base ai dati nel database e ai parametri passati (sniffing dei parametri), quindi memorizza nella cache questo piano. Ciò significa che se crei la query in cui ci sono 10 record nel tuo database e poi la esegui quando ci sono 100.000.000 di record, il piano di esecuzione memorizzato nella cache potrebbe non essere più il più efficace.
In sintesi, non vedo alcun motivo per cui OPTION(RECOMPILE) sarebbe un vantaggio qui. Sospetto che tu debba solo aggiornare le tue statistiche e il tuo piano di esecuzione. La ricostruzione delle statistiche può essere una parte essenziale del lavoro DBA a seconda della situazione. Se riscontri ancora problemi dopo aver aggiornato le tue statistiche, ti suggerisco di pubblicare entrambi i piani di esecuzione.
E per rispondere alla tua domanda:sì, direi che è molto insolito che la tua migliore opzione sia ricompilare il piano di esecuzione ogni volta che esegui la query.
