Dit is in de eerste plaats een kwestie van prestatie. Je hebt te maken met een slecht presterende code van jouw kant en je moet de bottleneck identificeren en aanpakken. Ik heb het over de slechte 2 seconden prestatie nu. Volg de richtlijnen op SQL Server-prestaties analyseren . Zodra u ervoor zorgt dat deze query lokaal wordt uitgevoerd voor een web-app (minder dan 5 ms), kunt u de vraag stellen of deze naar Azure SQL DB moet worden geporteerd. Op dit moment benadrukt uw proefaccount alleen de bestaande inefficiënties.
Na update
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
dus wat is het? is de iddepartment kolom een int of een nvarchar ? En waarom (max) gebruiken? ?
Dit is wat u moet doen:
- parameteriseer
@iddepartmentin de innerlijke dynamische SQL - stop met
nvarchar(max)conversie. Maak deiddepartmenten@iddertmenttypen komen overeen - zorg voor indexen op
iddepartmenten alleidkpis
Hier leest u hoe u de innerlijke SQL kunt parametriseren:
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 dekkingsindexen zijn verreweg de belangrijkste oplossing. Dat vereist uiteraard meer info dan hier aanwezig is. Lees Indexen ontwerpen inclusief alle subhoofdstukken.
Als een meer algemene opmerking:dit soort zoekopdrachten passen bij columnstores meer dan rowstore, hoewel ik denk dat de gegevensgrootte in feite klein is. Azure SQL DB ondersteunt updatebare geclusterde columnstore-indexen, u kunt ermee experimenteren in afwachting van een serieuze gegevensomvang. Ze vereisen inderdaad Enterprise/Development op de lokale box.