To je v první řadě otázka výkonu. Máte co do činění se špatně fungujícím kódem z vaší strany a musíte identifikovat úzké místo a vyřešit jej. Mluvím o špatných 2 sekundách výkon nyní. Postupujte podle pokynů na stránce Jak analyzovat výkon serveru SQL . Jakmile tento dotaz spustíte místně přijatelným pro webovou aplikaci (méně než 5 ms), můžete si položit otázku, jak jej přenést do Azure SQL DB. Právě teď váš zkušební účet pouze upozorňuje na existující neefektivitu.
Po aktualizaci
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
tak co to je? je iddepartment sloupec int nebo nvarchar ? A proč používat (max) ?
Zde je to, co byste měli udělat:
- parametrizovat
@iddepartmentve vnitřním dynamickém SQL - přestaňte dělat
nvarchar(max)konverze. Vytvořteiddepartmenta@iddertmenttypy se shodují - zajistit indexy na
iddepartmenta všechnyidkpis
Zde je návod, jak parametrizovat vnitřní 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;
Krycí indexy jsou zdaleka nejdůležitější opravou. To samozřejmě vyžaduje více informací, než je zde k dispozici. Přečtěte si Návrh indexů včetně všech podkapitol.
Jako obecnější komentář:tento druh dotazů se hodí columnstores více než rowstore, i když si myslím, že velikost dat je v zásadě malá. Azure SQL DB podporuje aktualizovatelné clusterované indexy columnstore, můžete s tím experimentovat v očekávání velké velikosti dat. Vyžadují Enterprise/Development na místním boxu, pravda.