Det här är först och främst en fråga om prestanda. Du har att göra med en dåligt fungerande kod från din sida och du måste identifiera flaskhalsen och åtgärda den. Jag pratar om de dåliga 2 sekunderna prestanda nu. Följ riktlinjerna på Hur man analyserar SQL Server-prestanda . När du får den här frågan att köras lokalt acceptabelt för en webbapp (mindre än 5 ms) kan du ställa frågan om att portera den till Azure SQL DB. Just nu framhäver ditt testkonto bara de befintliga ineffektiviteterna.
Efter uppdatering
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
så vad är det? är iddepartment kolumn en int eller en nvarchar ? Och varför använda (max) ?
Så här bör du göra:
- parameterisera
@iddepartmenti den inre dynamiska SQL - sluta med
nvarchar(max)omvandling. Göriddepartmentoch@iddertmenttyper matchar - säkerställ index på
iddepartmentoch allaidkpis
Så här parametrerar du den inre SQL:
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;
De täckande indexen är den absolut viktigaste fixen. Det kräver uppenbarligen mer information än vad som finns här. Läs Designa index inklusive alla underkapitel.
Som en mer allmän kommentar:den här typen av frågor passar kolumnbutiker mer än rowstore, även om jag tror att datastorleken i princip är liten. Azure SQL DB stöder uppdateringsbara klustrade kolumnlagerindex, du kan experimentera med det i väntan på allvarlig datastorlek. De kräver företag/utveckling på den lokala rutan, sant.