Azure 数据库上的慢查询操作答案

【问题标题】：Slow query operations on Azure databaseAzure 数据库上的慢查询操作
【发布时间】：2020-06-02 20:59:41
【问题描述】：

我在 Azure 数据表中有 120 万行。以下命令：

DELETE FROM _PPL_DETAIL WHERE RunId <> 229

非常缓慢。 RunId 上有一个索引。我正在删除大部分数据。 229 是少数记录。它已经运行了一个小时需要这么长时间吗？我很确定它会完成。我能做些什么来加快这样的操作吗？该数据库确实有一个 PK，尽管它是一个虚拟 PK（未使用）。我已经看到作为解决此问题的优化需要，但它仍然需要太长时间（SQL Server 以不同的方式对待没有 PK 的表 - 效率要低得多）。仍然需要 1 个多小时。

【问题讨论】：

标签： sql-server performance azure-sql-database processing-efficiency

【解决方案1】：

如果不知道哪个数据库层正在使用运行该语句的数据库，则很难为您提供帮助。但是，让我们告诉您系统是如何工作的，以便您自己进行更多调查来做出决定。

目前日志提交率受到数据库层级的限制。删除从根本上限制了写出日志记录的能力（并将它们复制到多台机器以防您的主机死机）。当您选择记录时，您不必通过网络访问 N 台机器，如果记录保存在内存中，您甚至可能不需要访问本地磁盘，因此通常预计选择比插入/更新更快/deletes 因为需要为您强化日志。您可以在此处阅读有关不同预订大小的具体限制：DTU Limits 和 vCore Limits。

一个常见的问题是在循环中执行单独的操作（如游标或从客户端驱动）。这意味着每条语句都更新了一行，因此必须连续加固每条日志记录，因为应用程序必须等待语句返回，然后才能提交下一条语句。由于您将大删除作为单个语句运行，因此您没有达到目标。由于其他原因，这可能会很慢，例如：

锁定 - 如果您有其他用户对表进行操作，它可能会阻止删除语句的进度。您可以通过查看 sys.dm_exec_requests 来了解您的语句是否阻塞了其他锁。
查询计划选择。如果您必须扫描大量行以删除一小部分，您可能会在 IO 上被阻止以查找它们。在这里查看查询计划形状会有所帮助，设置统计时间也会有所帮助（我们建议您将查询更改为执行 TOP 100 或类似操作，以了解您是在执行大量逻辑读取 IO 还是实际逻辑写入）。这可能意味着您的磁盘布局对于这个问题不是最理想的。一般的解决方案是选择更好的索引策略或使用分区来帮助您快速删除行组，而不必显式删除所有行。

另一个提高删除性能的策略是执行batching。

【讨论】：

此时，我是这个应用程序的唯一用户。 RunId 上有一个索引，但大部分记录都是 229（大部分记录正在被删除）。所以我认为这是天生的。但是您的善意输入和推荐的链接很有价值。那里有我不知道的好东西。谢谢。
除非您发布您的预订规模和您获得的查询计划，否则很难帮助您...

【解决方案2】：

据我所知，SQL Server 发生了变化，其服务器上的默认 DOP 为 1，因此如果您使用 OPTION(MAXDOP 0) 运行查询可能会有所帮助。

试试这个：

DELETE FROM _PPL_DETAIL
WHERE RunId <> 229
OPTION (MAXDOP 0);

【讨论】：

【解决方案3】：

试试下面的方法怎么样

BEGIN TRAN
SELECT * INTO #T FROM _PPL_DETAIL WHERE RunId = 229 
TRUNCATE TABLE _PPL_DETAIL
INSERT INTO _PPL_DETAIL
SELECT * FROM #T
COMMIT TRAN

【讨论】：

我喜欢你的想法。我认为它很有价值，但这不是我要寻找的答案。我正在寻找解决我的整体速度缓慢的方法，而删除只是其中的一部分......