Azure免费SQL数据库核心秒快速耗尽问题咨询

可能的原因 #

• 数据库自动暂停机制未触发：免费层SQL数据库默认闲置1小时后自动暂停，但后台维护任务（如索引重建、统计更新、平台健康检查）、隐性连接残留都可能阻止数据库进入暂停状态，导致持续消耗核心秒。
• 连接池未及时回收：即便函数显式关闭连接，数据库驱动或Azure函数的连接池可能保留闲置连接，这类连接会维持数据库活跃状态，无法触发暂停。
• 后台任务消耗占比高：Azure SQL的自动备份、日志备份、安全扫描等基础维护任务，在免费层有限的资源配额下，消耗占比会被放大。
• 查询实际消耗被低估：函数看似仅访问几秒，但未优化的查询（如全表扫描、复杂计算）可能单次就消耗远超预期的核心秒，累计起来快速耗尽配额。

排查与解决步骤 #

1. 核查数据库暂停状态
   登录Azure门户查看SQL数据库概述页，确认是否有频繁的暂停/恢复记录。若数据库长期处于活跃状态，说明存在阻止暂停的因素。

2. 分析核心秒消耗明细
   在数据库“使用情况”页面查看核心秒消耗趋势，定位消耗高峰时段，结合函数执行日志对比；同时查看后台任务的消耗占比。

3. 调整连接池设置
   若使用ADO.NET等驱动，可在连接字符串中临时添加 Max Pool Size=0 禁用连接池，测试核心秒消耗是否下降；或设置 Connection Lifetime=300（5分钟），让连接池自动回收闲置连接。

4. 优化高消耗查询
   执行以下SQL查询定位资源消耗高的语句，针对性添加索引或优化逻辑：

   SELECT TOP 10
       total_worker_time/execution_count AS avg_cpu_time,
       total_elapsed_time/execution_count AS avg_duration,
       total_logical_reads/execution_count AS avg_logical_reads,
       text
   FROM sys.dm_exec_query_stats
   CROSS APPLY sys.dm_exec_sql_text(sql_handle)
   ORDER BY total_worker_time DESC
   

5. 排查外部异常访问
   启用Azure SQL审计日志，检查是否存在未授权访问或意外的连接请求，这类请求也会消耗核心秒。

结论 #

核心秒快速耗尽并非免费账户默认设置问题，多由后台任务、连接池残留、未优化查询等因素导致，按上述步骤排查调整即可缓解。

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