FYI - você precisa estar ciente de outra coisa quando estiver trabalhando com SQL 2005 e procs armazenados com parâmetros.
O SQL Server compilará o plano de execução do proc armazenado com o primeiro parâmetro usado. Então, se você executar isso:
usp_QueryMyDataByState 'Rhode Island'
O plano de execução funcionará melhor com os dados de um estado pequeno. Mas se alguém se virar e correr:
usp_QueryMyDataByState 'Texas'
O plano de execução projetado para dados do tamanho de Rhode-Island pode não ser tão eficiente com dados do tamanho do Texas. Isso pode produzir resultados surpreendentes quando o servidor é reiniciado, porque o plano de execução recém-gerado será direcionado para qualquer parâmetro usado primeiro - não necessariamente o melhor. O plano não será recompilado até que haja uma grande razão para fazê-lo, como se as estatísticas fossem reconstruídas.
É aqui que entram os planos de consulta, e o SQL Server 2008 oferece muitos recursos novos que ajudam os DBAs a fixar um plano de consulta específico a longo prazo, não importa quais parâmetros sejam chamados primeiro.
Minha preocupação é que quando você reconstruiu seu proc armazenado, você forçou o plano de execução a recompilar. Você o chamou com seu parâmetro favorito e, claro, foi rápido - mas o problema pode não ter sido o proc armazenado. Pode ter sido que o proc armazenado foi recompilado em algum momento com um conjunto incomum de parâmetros e, portanto, um plano de consulta ineficiente. Você pode não ter corrigido nada e pode enfrentar o mesmo problema na próxima vez que o servidor for reiniciado ou o plano de consulta for recompilado.
