これは何よりもまずパフォーマンスの問題です。パフォーマンスの低いコードを処理しているため、ボトルネックを特定して対処する必要があります。悪い2秒について話している 今のパフォーマンス。 SQLServerのパフォーマンスを分析する方法のガイドラインに従ってください 。このクエリをWebアプリでローカルに受け入れられるように（5ミリ秒未満）実行すると、AzureSQLDBへの移植について質問できます。現在、トライアルアカウントは、既存の非効率性を強調しているだけです。
更新後
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
それで、それは何ですか？ iddepartmentです 列int またはnvarchar ？そして、なぜ(max)を使用するのか ？
すべきことは次のとおりです。
-
@iddepartmentのパラメータ化 内部動的SQLで -
nvarchar(max)の実行を停止します 変換。iddepartmentを作成します および@iddertmentタイプが一致する -
iddepartmentのインデックスを確認します およびすべてのidkpis
内部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;
カバーするインデックスは、これまでで最も重要な修正です。それには明らかに、ここにあるよりも多くの情報が必要です。 インデックスの設計 をお読みください すべてのサブチャプターを含みます。
より一般的なコメントとして：この種のクエリは列ストア に適しています データサイズは基本的に小さいと思いますが、行ストア以上のものです。 Azure SQL DBは、更新可能なクラスター化列ストアインデックスをサポートしているため、深刻なデータサイズを見越して実験することができます。確かに、ローカルボックスでのエンタープライズ/開発が必要です。