FYI - vous devez être conscient de quelque chose d'autre lorsque vous travaillez avec SQL 2005 et des procs stockés avec des paramètres.
SQL Server compilera le plan d'exécution de la procédure stockée avec le premier paramètre utilisé. Donc, si vous lancez ceci :
usp_QueryMyDataByState 'Rhode Island'
Le plan d'exécution fonctionnera mieux avec les données d'un petit état. Mais si quelqu'un se retourne et court :
usp_QueryMyDataByState 'Texas'
Le plan d'exécution conçu pour les données de taille Rhode-Island peut ne pas être aussi efficace avec les données de taille Texas. Cela peut produire des résultats surprenants lorsque le serveur est redémarré, car le plan d'exécution nouvellement généré sera ciblé sur le paramètre utilisé en premier - pas nécessairement le meilleur. Le plan ne sera pas recompilé tant qu'il n'y aura pas une bonne raison de le faire, comme si les statistiques étaient reconstruites.
C'est là qu'interviennent les plans de requête, et SQL Server 2008 offre de nombreuses nouvelles fonctionnalités qui aident les administrateurs de base de données à mettre en place un plan de requête particulier à long terme, quels que soient les paramètres appelés en premier.
Mon souci est que lorsque vous avez reconstruit votre proc stocké, vous avez forcé le plan d'exécution à se recompiler. Vous l'avez appelé avec votre paramètre préféré, et bien sûr c'était rapide - mais le problème n'était peut-être pas le proc stocké. Il se peut que la procédure stockée ait été recompilée à un moment donné avec un ensemble de paramètres inhabituel et, par conséquent, un plan de requête inefficace. Vous n'avez peut-être rien corrigé et vous pourriez rencontrer le même problème la prochaine fois que le serveur redémarrera ou que le plan de requête sera recompilé.
