Azure SQL弹性池同查询CPU耗时差异巨大问题排查求助

结合你提供的信息（相同执行计划、数据无变化、两次均从缓存取计划），性能差异大概率和Azure SQL弹性池的托管特性以及资源状态相关，具体原因如下：

• 弹性池资源共享与后台抢占
  Azure SQL弹性池的CPU、内存是池内所有数据库共享的。即使你监控显示“完全空闲”，周末凌晨可能正赶上Azure后台维护任务（比如自动备份、索引优化、存储层数据整理、统计信息自动更新增量任务），这些隐性操作会占用池内CPU资源，导致你的查询能分配到的CPU时间片被压缩，表现为CPU耗时剧增。长耗时执行的等待类型为CPU，也印证了查询在等待CPU资源的情况。

• 缓冲池数据页的冷热差异
  弹性池的缓冲池（内存）会根据池内负载动态调整。周末池空闲时，缓冲池可能被收缩，你的查询涉及的数据页被从内存中驱逐到磁盘。当执行查询时，需要重新从磁盘加载数据页到内存，这个过程会伴随额外的CPU开销（比如数据校验、解压、内存页分配），导致CPU耗时变长。而周一重新执行时，数据页已经被加载回缓冲池，完全从内存读取，CPU开销骤降。

• CPU节流机制触发
  弹性池有CPU资源的阈值限制，当池内累计CPU使用率接近上限时，Azure会自动对查询进行节流（限制CPU使用率）。周末那次执行可能刚好遇到后台任务占用了大量CPU，触发了节流，导致查询的CPU执行被延迟，体现为CPU耗时长达29秒。周一凌晨后台任务完成，池内资源充足，没有节流，查询快速执行。

• 统计信息的临时异常（可能性较低）
  虽然数据量无明显变化，但Azure SQL的自动统计信息更新可能在周末触发了增量更新，导致统计信息短暂处于stale状态。不过两次执行使用了同一个执行计划，这个因素的影响相对较小，但也不能完全排除统计信息变化导致执行时的CPU开销波动。

补充说明：你提到的“Azure SQL无服务器环境”其实和弹性池是不同的托管模式，但弹性池作为Azure的托管SQL服务，上述的资源动态调度、后台维护、缓冲池调整等都是其核心特性，也是导致本次性能差异的关键因素。

内容的提问来源于stack exchange，提问作者Simon Norton