Mengapa menjalankan kueri pada SQL Azure jauh lebih lambat?

Ini adalah pertama dan terutama pertanyaan kinerja. Anda berurusan dengan kode yang berkinerja buruk di pihak Anda dan Anda harus mengidentifikasi hambatan dan mengatasinya. Saya sedang berbicara tentang yang buruk 2 detik kinerja sekarang. Ikuti panduan di Cara menganalisis kinerja SQL Server . Setelah Anda mendapatkan kueri ini untuk dieksekusi secara lokal yang dapat diterima untuk aplikasi web (kurang dari 5 md), Anda dapat mengajukan pertanyaan untuk mem-portingnya ke Azure SQL DB. Saat ini akun uji coba Anda hanya menyoroti inefisiensi yang ada.

Setelah pembaruan

...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...

jadi apa itu? adalah iddepartment kolom sebuah int atau nvarchar ? Dan mengapa menggunakan (max) ?

Inilah yang harus Anda lakukan:

• parameterisasikan @iddepartment dalam SQL dinamis dalam
• berhenti melakukan nvarchar(max) konversi. Buat iddepartment dan @iddertment jenis cocok
• pastikan indeks pada iddepartment dan semua idkpi s

Berikut adalah cara membuat parameter SQL bagian dalam:

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;

Indeks penutup, sejauh ini, merupakan perbaikan yang paling penting. Itu jelas membutuhkan lebih banyak info daripada yang ada di sini. Baca Mendesain Indeks termasuk semua sub-bab.

Sebagai komentar yang lebih umum:kueri semacam ini cocok untuk columnstores lebih dari rowstore, meskipun menurut saya ukuran data pada dasarnya kecil. Azure SQL DB mendukung indeks penyimpanan kolom berkerumun yang dapat diperbarui, Anda dapat bereksperimen dengannya untuk mengantisipasi ukuran data yang serius. Mereka memang membutuhkan Perusahaan/Pengembangan di kotak lokal, benar.