Esta é, antes de tudo, uma questão de desempenho. Você está lidando com um código de baixo desempenho de sua parte e deve identificar o gargalo e resolvê-lo. Estou falando dos ruins 2 segundos desempenho agora. Siga as diretrizes em Como analisar o desempenho do SQL Server . Depois de obter essa consulta para executar localmente aceitável para um aplicativo Web (menos de 5 ms), você pode fazer a pergunta de portá-la para o banco de dados SQL do Azure. No momento, sua conta de teste está apenas destacando as ineficiências existentes.
Após a atualização
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
Então o que é? é o
iddepartment coluna um int ou um nvarchar ? E por que usar (max) ? Aqui está o que você deveria fazer:
- parametrizar
@iddepartmentno SQL dinâmico interno - pare de fazer
nvarchar(max)conversão. Faça oiddepartmente@iddertmentos tipos correspondem - garantir índices em
iddepartmente todos osidkpis
Veja como parametrizar o SQL interno:
set @sql =N'
Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay
from kpi
inner join kpivalues on kpivalues.idkpi=kpi.idkpi
inner join kpitarget on kpitarget.idkpi=kpi.idkpi
inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi
where [email protected]
group by kpiname,target, ivalues,idate)x
pivot
(
avg(ivalues)
for iDay in (' [email protected] + N')
) p'
execute sp_executesql @sql, N'@iddepartment INT', @iddepartment;
Os índices de cobertura são, de longe, a correção mais importante. Isso obviamente requer mais informações do que as que estão aqui presentes. Leia Projetando índices incluindo todos os subcapítulos.
Como um comentário mais geral:esse tipo de consulta convém a columnstores mais do que rowstore, embora eu ache que o tamanho dos dados seja, basicamente, minúsculo. O banco de dados SQL do Azure dá suporte a índices columnstore clusterizados atualizáveis, você pode experimentá-lo antecipando o tamanho dos dados sérios. Eles exigem Enterprise/Development na caixa local, é verdade.
