Eu tenho um pedaço de SQL que parece rodar muito rápido no Ambiente A, mas a mesma consulta é muito lenta no Ambiente B!
Os ambientes devem ser os mesmos, então o que devo fazer e/ou onde devo procurar para ver por que a consulta não executa o mesmo?
Existem muitos fatores internos e externos ao SQL Server que podem fazer com que a mesma consulta tenha um desempenho diferente em ambientes diferentes, mesmo quando configurados exatamente da mesma forma, qualquer um dos quais pode resultar em planos de consulta e desempenho muito diferentes.
Servidor
Instância
Base de dados
Com tudo isso em mente, não é surpreendente que, em muitos casos, simplesmente não seja possível copiar perfeitamente todos os aspectos de um banco de dados em diferentes ambientes. Embora os testes possam fornecer um bom grau de certeza sobre o desempenho das consultas em cada ambiente, não deve ser surpresa se houver discrepâncias entre os ambientes. Ao desenvolver uma nova consulta, geralmente é necessário um ajuste adicional à medida que avança para a produção.
Normalmente, ajustar uma consulta mais lenta em um ambiente não deve causar regressões nos planos de execução gerados, portanto, é uma oportunidade de ajustar índices, estatísticas ou a própria consulta para uma melhoria geral.
Observação final: ambientes inferiores são subdimensionados e, muitas vezes, não se espera que forneçam o mesmo desempenho de um ambiente de produção ou pré-produção.
Mais recursos:
As outras respostas são boas, mas eu acrescentaria que você deve considerar a quantidade de dados no Ambiente B e qualquer contenção com outras consultas.
Algumas consultas SQL não mostram problemas de desempenho isoladamente (por exemplo, 1000 linhas na tabela, nenhuma outra consulta em execução), mas podem ser horríveis com 10.000.000 linhas na tabela (por exemplo, problemas de detecção de parâmetros) e/ou outras consultas potencialmente gravando, atualizando ou bloqueando as tabelas envolvidas.
Eu concordo com as outras respostas sobre como verificar a correspondência de hardware/ambientes/configurações primeiro, mas se nada óbvio aparecer, comece a examinar os planos de execução de consultas, executar o SQL Profiler etc.
Resumindo, você precisa isolar se o próprio db é lento em relação ao outro, ou se o ambiente dele é mais lento. Descarte as coisas mais fáceis primeiro.
Isso já aconteceu comigo algumas vezes. Cada vez que se tratava de ambiente: outra pessoa estava martelando e privando o banco de dados de IOPS em um servidor.
Execute um top(1) no servidor mais lento e veja se a CPU está enfrentando grandes quantidades de estados de espera ou roubo de CPU se você estiver em um ambiente virtual.
Isso também ajudará a apontar para índices ausentes que fazem com que os planos de execução executem verificações de tabela completas em vez de verificações de índice (mas isso é fácil de detectar com log de consulta lento). Isso também aparecerá em ps como procs em um estado D.
Uma vez que você descartou isso, é hora de cavar mais fundo no hardware: o trabalho está sendo espalhado por todas as CPUs, tem uma porta de rede renegociada para 100Mb. Execute vmstat e/ou iostat em ambas as máquinas e compare as diferenças.
Se os conjuntos de dados forem idênticos, a mesma consulta gera o mesmo plano de execução em ambos? As tabelas contêm o mesmo número de linhas? As definições de índice são idênticas? As tabelas têm níveis semelhantes de fragmentação? Números semelhantes de conexões ativas?