Há momentos em que usar
OPTION(RECOMPILE) faz sentido. Na minha experiência, a única vez que essa é uma opção viável é quando você está usando SQL dinâmico. Antes de explorar se isso faz sentido em sua situação, recomendo reconstruir suas estatísticas. Isso pode ser feito executando o seguinte:EXEC sp_updatestats
E, em seguida, recriar seu plano de execução. Isso garantirá que, quando seu plano de execução for criado, ele usará as informações mais recentes.
Adicionando
OPTION(RECOMPILE) reconstrói o plano de execução sempre que sua consulta é executada. Eu nunca ouvi isso descrito como creates a new lookup strategy mas talvez estejamos apenas usando termos diferentes para a mesma coisa. Quando um procedimento armazenado é criado (suspeito que você esteja chamando sql ad-hoc do .NET, mas se você estiver usando uma consulta parametrizada, isso acaba sendo uma chamada de proc armazenado) o SQL Server tenta determinar o plano de execução mais eficaz para essa consulta com base nos dados em seu banco de dados e nos parâmetros passados (sniffing de parâmetros) e, em seguida, armazena em cache esse plano. Isso significa que, se você criar a consulta onde houver 10 registros em seu banco de dados e executá-la quando houver 100.000.000 de registros, o plano de execução em cache poderá não ser mais o mais eficaz.
Em resumo - não vejo nenhum motivo para
OPTION(RECOMPILE) seria um benefício aqui. Suspeito que você só precise atualizar suas estatísticas e seu plano de execução. A reconstrução de estatísticas pode ser uma parte essencial do trabalho do DBA, dependendo da sua situação. Se você ainda estiver tendo problemas após atualizar suas estatísticas, sugiro postar os dois planos de execução. E para responder à sua pergunta - sim, eu diria que é altamente incomum que sua melhor opção seja recompilar o plano de execução toda vez que você executar a consulta.
