VarBinary(max) 在 SQL Azure 上更新非常慢

Posted 2023-04-15

【中文标题】VarBinary(max) 在 SQL Azure 上更新非常慢

【英文标题】：VarBinary(max) updates very slow on SQL Azure

【发布时间】：2017-10-24 13:33:28

【问题描述】：

我们将一些文档存储在 SQL Server 数据库的VarBinary(Max) 列中。大多数文档只有几 KB，但有时可能只有几 MB。

当文件大于大约 4MB 时，我们会遇到问题。

在本地 SQL Server 中更新 VarBinary 列时，速度非常快（8MB 文件只需 0.6 秒）。

在 SQL Azure 上对相同的数据库执行相同的语句时，需要超过 15 秒！

另外，如果代码是从 Azure 应用服务运行的，它会非常慢。所以问题不在于我们的互联网连接。

我知道在 SQL Server 中存储文件不是首选的存储方式，Blob 存储通常是最好的解决方案，但是我们有特殊的原因需要这样做，所以我想把它排除在讨论之外 ;-)

在调查执行计划时，我发现“表假脱机”一直在占用，但我不确定原因。以下是 on prem 和 Azure 的执行计划。

相同的数据库和数据。如果有人可以提供帮助，那就太好了。

谢谢克里斯

【问题讨论】：

在 dba.stackexchange.com 上发布您的问题

表扫描，Id 上没有索引？

嗨@TapakahUa，感谢您的评论。它的表只有 5 条记录，所以缺少的索引应该无关紧要。而且因为我想排除索引的更新（以及它的统计数据）是原因，所以我删除了索引。它在真正的桌子上。表扫描仅需 0.004 秒。

什么是服务层和DTU级别，事务期间哪个DTU组件被最大化？

@david 此测试数据库位于 50 eDTU 弹性数据库池上。基础层。没想到！当我回到办公室时，我会在标准层上尝试同样的方法，然后告诉你结果。谢谢

【参考方案1】：

表假脱机操作员正在缓存要更新的行（在 tempdb 中），然后将其提供给表更新操作员，假脱机操作员表示数据库引擎正在执行大量写入（8 KB 页）到临时数据库。

对于 I/O 密集型工作负载，您需要扩展到高级层。在基本和标准层上，这些更新不会有良好的性能。

希望这会有所帮助。

【讨论】：

谢谢@Alberto。将其标记为答案

祝您有美好的一天！谢谢！