Isso é um pouco longo; mas tenho trabalhado em consultas para descobrir de onde vem um problema de desempenho. Aprecio você ter tempo para lê-lo.
Eu tenho um aplicativo em execução em um Servidor Dedicado que está em execução no SQL Server 2012 @ Azure (Europa Ocidental, se isso for importante). Meu aplicativo não será executado no serviço compartilhado devido a lacunas de funcionalidade no Azuresql. O aplicativo que está em execução foi executado em todos os tipos de servidores de 2012 no passado e estou percebendo uma anomalia estranha de desempenho entre o Azure e outros servidores SQL não azuis.
O problema está em torno de tabelas temporárias - tabelas variáveis v # tabelas novamente.
Estamos descobrindo no Azure que as tabelas variantes das durações das consultas são consideravelmente mais longas; exemplo muito simples; executar 50 vezes cada e calcular a média.
Create table #table (contactid uniqueidentifier, AnotherID uniqueidentifier)
insert into #table
select top 100 contactid, AnotherID
from dbo.pdContacts
v
declare @table table (contactid uniqueidentifier, AnotherID uniqueidentifier)
insert into @table
select top 100 contactid, AnotherID
from dbo.pdContacts
Profiler diz que a média das estatísticas é de
Variable Table : #Table
CPU 47 : 16
Reads 379 : 204
Writes 11 : 0
Duration 83 : 42
A mesma consulta, bancos de dados em um servidor dedicado e sem carga retornada
Variable Table : #Table
CPU 16 : 16
Reads 873 : 898
Writes 11 : 0
Duration 5 : 15
No meu teste muito simples, o teste Variante do Azure é quase o dobro da duração de execução que a #table; em equipamentos independentes, a variante é consideravelmente mais rápida (o que, para tabelas pequenas, é consistente com a forma como a vimos funcionar). O que restringe o desempenho das tabelas de variantes mais perceptível no Azure do que as máquinas independentes; Eu posso gerenciar os problemas de desempenho a curto prazo, mas preferiria não otimizar o aplicativo para o azure às custas de todos os outros.
Obrigado