Pourquoi l'exécution d'une requête sur SQL Azure est-elle tellement plus lente ?

C'est avant tout une question de performance. Vous avez affaire à un code peu performant de votre part et vous devez identifier le goulot d'étranglement et y remédier. Je parle des mauvaises 2 secondes performances maintenant. Suivez les directives sur Comment analyser les performances de SQL Server . Une fois que vous avez obtenu que cette requête s'exécute localement acceptable pour une application Web (moins de 5 ms), vous pouvez alors poser la question de la porter sur Azure SQL DB. Pour le moment, votre compte d'essai ne fait que mettre en évidence les inefficacités existantes.

Après la mise à jour

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

alors c'est quoi? est le iddepartment colonne un int ou un nvarchar ? Et pourquoi utiliser (max) ?

Voici ce que vous devez faire :

• paramétrer @iddepartment dans le SQL dynamique interne
• arrêter de faire nvarchar(max) conversion. Faites le iddepartment et @iddertment les types correspondent
• assurer les index sur iddepartment et tous les idkpi s

Voici comment paramétrer le SQL interne :

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;

Les index de couverture sont, de loin, la solution la plus importante. Cela nécessite évidemment plus d'informations qu'il n'y en a ici. Lire Concevoir des index y compris tous les sous-chapitres.

En tant que commentaire plus général :ce type de requêtes convient aux columnstores plus que rowstore, même si je pense que la taille des données est, fondamentalement, minuscule. Azure SQL DB prend en charge les index columnstore en cluster pouvant être mis à jour, vous pouvez l'expérimenter en prévision d'une taille de données importante. Ils ont besoin d'Enterprise/Development sur la boîte locale, c'est vrai.