Il arrive parfois que l'utilisation de OPTION(RECOMPILE) logique. D'après mon expérience, la seule fois où cette option est viable, c'est lorsque vous utilisez SQL dynamique. Avant d'explorer si cela a du sens dans votre situation, je vous recommande de reconstruire vos statistiques. Cela peut être fait en exécutant ce qui suit :
EXEC sp_updatestats
Et puis recréer votre plan d'exécution. Cela garantira que lorsque votre plan d'exécution sera créé, il utilisera les informations les plus récentes.
Ajout de OPTION(RECOMPILE) reconstruit le plan d'exécution à chaque exécution de votre requête. Je n'ai jamais entendu dire que creates a new lookup strategy mais peut-être utilisons-nous simplement des termes différents pour la même chose.
Lorsqu'une procédure stockée est créée (je soupçonne que vous appelez ad-hoc sql à partir de .NET mais si vous utilisez une requête paramétrée, cela finit par être un appel de proc stocké) SQL Server tente de déterminer le plan d'exécution le plus efficace pour cette requête en fonction des données de votre base de données et des paramètres transmis (reniflage de paramètres), puis met en cache ce plan. Cela signifie que si vous créez la requête là où il y a 10 enregistrements dans votre base de données, puis que vous l'exécutez lorsqu'il y a 100 000 000 enregistrements, le plan d'exécution mis en cache peut ne plus être le plus efficace.
En résumé - je ne vois aucune raison pour laquelle OPTION(RECOMPILE) serait un avantage ici. Je soupçonne que vous avez juste besoin de mettre à jour vos statistiques et votre plan d'exécution. La reconstruction des statistiques peut être une partie essentielle du travail du DBA en fonction de votre situation. Si vous rencontrez toujours des problèmes après la mise à jour de vos statistiques, je vous suggère de publier les deux plans d'exécution.
Et pour répondre à votre question - oui, je dirais qu'il est très inhabituel pour votre meilleure option de recompiler le plan d'exécution à chaque fois que vous exécutez la requête.
