任何人都可以告诉我为什么可能需要12秒以上才能在Azure上托管的SQL数据库中插入1000行?我刚刚开始使用Azure,这显然是荒谬的......
main {background-color: red;}
输出:
Create Table xyz (ID int primary key identity(1,1), FirstName varchar(20))
GO
create procedure InsertSomeRows as
set nocount on
Declare @StartTime datetime = getdate()
Declare @x int = 0;
While @X < 1000
Begin
insert into xyz (FirstName) select 'john'
Set @X = @X+1;
End
Select count(*) as Rows, DateDiff(SECOND, @StartTime, GetDate()) as SecondsPassed
from xyz
GO
Exec InsertSomeRows
Exec InsertSomeRows
Exec InsertSomeRows
GO
Drop Table xyz
Drop Procedure InsertSomeRows
答案 0 :(得分:3)
您所处的性能等级可能导致此问题。使用标准S0层,您只有10个DTU(数据库吞吐量单位)。如果您还没有,请阅读SQL Database Service Tiers。如果您不熟悉DTU,那么它与本地SQL Server有点不同。 CPU,内存,日志IO和数据IO的数量都包含在您选择的服务层中。就像在现场一样,如果你开始达到机器可以处理速度减慢的上限,开始排队并最终开始超时。
按照您的操作再次运行测试,然后使用Azure门户观察测试正在进行时使用的DTU%。如果您发现DTU%已达到最大限度,则问题在于您选择的服务层没有足够的资源来处理您的应用而不会减速。如果速度不可接受,则向上移动到下一个服务层,直到速度可以接受。您需要支付更多费用才能获得更
我建议不要过分关注基于此测试的服务层,而应关注要应用于生产系统的实际负载。此测试将为您提供一个想法并更好地理解DTU,但它可能代表或可能不代表您的生产负载所需的实际吞吐量(可能更重!)。
不要忘记,在Azure SQL DB中,您还可以根据需要扩展数据库,以便获得所需的性能,但可以在不需要的时候退回。在大多数缩放操作期间可以访问数据库(但是请注意,它可能需要一些时间来执行缩放操作,并且可能存在第二个或两个无法连接)。
答案 1 :(得分:3)
两个因素造成了最大的不同。首先,我将所有插入包装到一个事务中。这让我从每秒100次插入到2500左右。然后我将服务器升级到PREMIUM P4层,现在我可以每秒插入25,000(在交易中)。
这需要一些人习惯使用Azure服务器以及哪些最佳实践能够为我提供所需的结果。
答案 2 :(得分:1)
我的理论:每个插入都是一个日志IO。在这里,这将是100 IOs /秒。这听起来像是对S0的合理限制。你可以尝试用插件包裹的事务吗?
因此,在单个事务中包装插入确实加快了速度。在事务内部,它可以插入大约每秒2500行
所以这就解释了。现在结果不再是灾难性的。我现在建议查看指标,例如Azure仪表板DTU利用率和等待统计数据。如果你在这里张贴它们我会看看。
答案 3 :(得分:0)
提高性能的一种方法是查看查询的等待统计信息
查看等待统计信息,在查询运行时会给你准确的瓶颈。在你的情况下,它原来是LOGIO ..在这里了解更多关于这种方法:SQL Server Performance Tuning Using Wait Statistics
另外我建议将while循环更改为基于某些东西设置,如果此查询不是Psuedo查询并且您经常运行此
基于设置的解决方案:
create proc usp_test
(
@n int
)
Begin
begin try
begin tran
insert into yourtable
select n ,'John' from
numbers
where n<@n
commit
begin catch
--catch errors
end catch
end try
end
您必须创建numbers表才能使其正常工作
答案 4 :(得分:0)
在发现一些技巧之前,我在Azure中存在有关更新和删除的可怕性能问题:
将数据复制到临时表并在临时表中进行更新,然后在完成后复制回永久表。
在要更新的表上创建聚簇索引(分区也不起作用)
对于插入,我正在使用批量插入并获得可接受的性能。