对于我的一个客户，我们有一个用于存储数据的大型Azure SQL DB，每天都在使用。我们有一个每晚多次创建和更新数据的流程(C#(。在此过程中，还会在数据库中插入、删除和更新数据。一段时间以来，我们在这个过程中遇到了问题，这个过程经常中途停止。在这个过程的日志记录中，我们看到它通常在DB操作时停止，最常见的是在DELETE步骤。
因此，我们得出的结论是，查询花费的时间太长，因此进程会自行终止。数据库的其他用户，查询数据库以进行报告等，最近也遇到了问题，查询需要很长时间才能完成或根本无法完成。
我注意到的一件事是，在处理过程中，LOG/IO百分比经常会上升到100%。我曾尝试更改DB中的一些缩放配置，但这似乎不会影响任何事情。
值得注意的是，每晚都有数亿行被更新/插入/删除。
截至目前，数据库为GEN5，8个Vcores，1.5 TB内存(目前实际大小为280GB，但在年底之前每天都会增加，届时我们通常会归档并创建一个新的数据库(。
我真的很感激关于如何提高这个DB的性能以及我们可以对高LOG/IO百分比做些什么的提示和/或技巧。
我已经尝试过更新指数，但碎片化程度似乎并不特别高。
例如高LOG/IO。
如果您的日志I/O达到100%，那么这将是因为您正在敲打数据库日志文件。创建/更新/删除数百万行就可以做到这一点。
如果没有具体流程的细节，很难确切地说出来，但我大胆猜测，你没有批量执行创建/更新/删除操作。也就是说，如果您有5000万行要创建，5000万行需要更新，5000万行将删除，那么您可以执行以下操作：
BEGIN TRANSACTION
DELETE * FROM Table WHERE ID between 0 and 50000000
COMMIT
在该操作完成之前，数据将存储在SQL Server日志文件中；一旦它完成并且SQL Server执行它的一个定期CHECKPOINT，它就会将数据刷新到磁盘，并且日志文件会被截断。
因此，一个建议是批量处理过夜的流程，这样每个事务只影响总数据集的一小部分；举我上面的例子，你可以这样做：
DECLARE @ID INT = 0
DECLARE @IDTop INT
WHILE @ID < 50000001
BEGIN
WAITFOR DELAY '00:00:01'
SET @IDTop = @ID + 10000
BEGIN TRANSACTION
DELETE * FROM Table
WHERE ID between @ID and @IDTop
COMMIT
SET @ID = @IDTop
END
它将在10000个行块中迭代——这显然是一个例子，可以进行调整，但应该会给你一个关于结构的想法。