Questa è prima di tutto una questione di prestazioni. Hai a che fare con un codice poco performante da parte tua e devi identificare il collo di bottiglia e risolverlo. Sto parlando dei cattivi 2 secondi prestazioni ora. Segui le linee guida in Come analizzare le prestazioni di SQL Server . Una volta ottenuta questa query per l'esecuzione in locale accettabile per un'app Web (meno di 5 ms), è possibile porre la domanda di portarla nel database SQL di Azure. In questo momento il tuo account di prova sta solo evidenziando le inefficienze esistenti.
Dopo l'aggiornamento
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
quindi, cos'è? è il iddepartment colonna un int o un nvarchar ? E perché usare (max) ?
Ecco cosa dovresti fare:
- parametrizza
@iddepartmentnell'SQL dinamico interno - smetti di fare
nvarchar(max)conversione. Crea iliddepartmente@iddertmenti tipi corrispondono - assicura gli indici su
iddepartmente tutti gliidkpis
Ecco come parametrizzare l'SQL interno:
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;
Gli indici di copertura sono, di gran lunga, la soluzione più importante. Ciò ovviamente richiede più informazioni di quelle qui presenti. Leggi Progettazione di indici compresi tutti i sottocapitoli.
Come commento più generale:questo tipo di query si adatta a columnstores più di rowstore, anche se ritengo che la dimensione dei dati sia, fondamentalmente, piccola. Il database SQL di Azure supporta gli indici columnstore cluster aggiornabili, puoi sperimentarlo in previsione di grandi dimensioni dei dati. Richiedono Impresa/Sviluppo sulla casella locale, vero.
