Question

我有一个具有S0定价层的Azure数据库。运行存储过程时，大约需要20秒才能在我的ASP.NET网站和SSMS中显示结果。

现在，我将价格等级降为基本。当我运行相同的存储过程时，它在ASP.NET网站中显示消息超时。当我在SSMS中执行存储过程时，大约需要35秒。

我分析我的数据库。从实际的执行计划选项卡中，建议我创建一个索引。我遵循这个建议。我在表中创建一些索引。结果在我的ASP.NET网站中仅需1-2秒即可显示结果。但是在SSMS中，加载时间不会改变。还需要35秒。

我已经关闭SSMS并再次重新连接azure数据库，但它不会更改加载时间。我的SSMS是SSMS 2016（版本13.0.16106.4）

我的Azure数据库会怎样？

Answer 1

今天，在我再次尝试存储过程之后，结果使我感到惊讶。 SSMS和ASP.NET网站都需要很长时间。在ASP.NET网站上显示超时页面。在SSMS中，显示数据大约需要30-35秒。我对Azure非常困惑。所以，现在我的问题是此存储过程选择数据的速度很慢。

因此，我交叉检查了我的存储过程。我更改了存储过程的格式，直接选择值来运行select命令，删除参数，等等。结果，存储过程现在只需要1-2秒即可加载数据。

下面，我根据自己的经验写一些总结：

如果您的存储过程在select语句中使用了一些FORMAT，并且存储过程具有DATE参数，它将非常慢。
在select语句中不要使用太多FORMAT。如果你想格式化值，在ASP.NET或C＃中执行。
将FORMAT更改为CONVERT，因为根据我的经验，FORMAT使性能下降。

这是我更改的代码，比它提高了存储过程的性能：

之前

FORMAT(b.tglTransaksi,'dd-MM-yy','en-US') AS [Tanggal],
FORMAT((a.upTime+'07:00'),'HH:mm:ss','en-US') AS [Waktu Input],
FORMAT(a.idMaster,'0000000#','en-US') AS [No. Ref],

之后

CONVERT(CHAR(8),b.tglTransaksi,5) AS [Tanggal],
CONVERT(CHAR(8),a.upTime+'07:00',108) AS [Waktu Input],
RIGHT('00000000'+CAST(a.idMaster AS VARCHAR(8)),8) AS [No. Ref],

也许这种经历可以帮助其他人。

Azure数据库中的存储过程在ASP.NET中运行快，而在SSMS中运行慢

1 个答案: