sql-server - 为什么在空闲的 10 核池上，Azure SQL 查询有时会使用 29 秒的 CPU，其他时候则使用 0.1 毫秒？

Question

使用具有 10 个核心的 Azure SQL 弹性池，当其完全空闲时(周末)，查询存储显示 SP/查询使用了 29 秒的 CPU，并导致在 80% 时触发高平均 CPU 使用率警报。

我在接下来的周一清晨重新创建了池也空闲的情况，并使用相同的参数值启动了 SP/Query，并在 sys.dm_exec_query_stats 中观察结果。
CPU大约是0.1毫秒。查询存储显示它使用相同的 QueryId、相同的 PlanId、在整个计划中均匀分布的相同负载分布。此外，该计划并没有并行。

由于是一个周末，表中的数据量没有发生任何可测量的变化。我还检查了 SP 返回的数据在该事件发生前几个月就已经存在，因此这不是结果在两次之间发生变化的情况。

我更像是一名开发人员，而不是一名 DBA，所以有人可以在其他地方寻找查询在明显相同的环境下执行如此巨大差异的原因和方式吗？这种现象是否与Azure SQL的无服务器环境有关？

评论中要求的更多统计数据:

• 两次查询运行的编译时间分别为 77 毫秒和 47 毫秒 CPU。
• 在这两个实例中均从缓存中检索了计划。
• 等待时间似乎不适用于短期运行。
• 长时间运行的等待时间为“CPU”6303ms。

非常感谢您的帮助!

Answer 1

这是标准 SQL Server 模式。第一次运行查询时，它必须执行大量物理 IO、内存分配增加并且速度很慢。您可以查看执行缓慢的查询，它们可能显示 PAGEIOLATCH_SH 和 MEMORY_ALLOCATION_EXT 等待，这对应于从磁盘拉到缓冲区的页面。第二次运行查询时，数据位于缓冲区中，而且速度很快。

一段时间不活动后，内存分配会下降。在数据库一段时间未使用或数据库层纵向扩展或纵向扩展后，Azure SQL 数据库会收缩内存分配。您将在 Azure SQL 数据库上看到这种情况发生，但在 SQL Server 实例 (IaaS) 上则不会。如果将数据库设置为无服务器，您将看到内存被更频繁地回收，如您在 Azure SQL Serverless 文档 here 中所读到的那样。 ，这对性能有更大的影响。

另一个可能的原因是查询正在等待同步统计信息更新完成，然后才能恢复执行。请尝试按照说明启用异步更新统计信息 here 。定期更新统计信息消除索引碎片也可以提高性能，因此无需在执行查询之前更新统计信息，因为它们是由维护作业定期更新的。