Dette er først og fremmest et spørgsmål om præstation. Du har at gøre med en dårligt fungerende kode fra din side, og du skal identificere flaskehalsen og adressere den. Jeg taler om de dårlige 2 sekunder præstation nu. Følg retningslinjerne på Sådan analyserer du SQL Server-ydeevne . Når du får denne forespørgsel til at udføre lokalt acceptabel for en webapp (mindre end 5 ms), kan du stille spørgsmålet om at portere den til Azure SQL DB. Lige nu fremhæver din prøvekonto kun de eksisterende ineffektiviteter.
Efter opdatering
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
så hvad er det? er iddepartment kolonne en int eller en nvarchar ? Og hvorfor bruge (max) ?
Her er, hvad du skal gøre:
- parametriser
@iddepartmenti den indre dynamiske SQL - stop med at gøre
nvarchar(max)konvertering. Laviddepartmentog@iddertmenttyper matcher - sørg for indekser på
iddepartmentog alleidkpis
Sådan parametreres den indre 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 dækkende indekser er langt den vigtigste rettelse. Det kræver naturligvis mere information, end der er til stede her. Læs Designing indekser inklusive alle underkapitler.
Som en mere generel kommentar:denne slags forespørgsler passer til kolonnebutikker mere end rowstore, selvom jeg regner med, at datastørrelsen dybest set er lille. Azure SQL DB understøtter opdaterbare clustered columnstore-indekser, du kan eksperimentere med det i forventning om alvorlige datastørrelser. De kræver Enterprise/Udvikling på den lokale boks, sandt.