Това е преди всичко въпрос на производителност. Имате работа с лошо представящ се код от ваша страна и трябва да идентифицирате затруднението и да го преодолеете. Говоря за лошите 2 секунди изпълнение сега. Следвайте указанията в Как да анализирате производителността на SQL Server . След като получите тази заявка да се изпълни локално приемливо за уеб приложение (по-малко от 5 ms), тогава можете да зададете въпроса за пренасянето й в Azure SQL DB. В момента пробният ви акаунт само подчертава съществуващите неефективности.
След актуализация
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
така че какво е това? е iddepartment колона int или nvarchar ? И защо да използвате (max) ?
Ето какво трябва да направите:
- параметризиране на
@iddepartmentвъв вътрешния динамичен SQL - спри да правиш
nvarchar(max)преобразуване. Направетеiddepartmentи@iddertmentтипове съвпадат - осигурете индекси на
iddepartmentи всичкиidkpiс
Ето как да параметризирате вътрешния 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;
Покриващите индекси са най-важното решение. Това очевидно изисква повече информация, отколкото е тук. Прочетете Проектиране на индекси включително всички подглави.
Като по-общ коментар:този вид заявки са подходящи за columnstores повече от rowstore, въпреки че смятам, че размерът на данните по принцип е малък. Azure SQL DB поддържа обновяеми клъстерни индекси на columnstore, можете да експериментирате с него в очакване на сериозен размер на данните. Те изискват Enterprise/Development на локалната кутия, вярно.
