Azure SQL平台升级后执行建表脚本引发CPU占满及数据库无法登录问题咨询

首先得说，生产环境遇到这种彻底卡死的情况真的太闹心了，尤其是刚经历过平台升级之后，确实很容易把两者关联起来。

先聊聊你的理论：主库同步变更到可用性区域副本时锁死，这种可能性是完全存在的，但需要结合一些细节来验证。Business Critical tier本身依赖Always On可用性组来同步副本，平台升级后可能副本的状态、同步机制存在一些隐性异常——虽然健康事件标了已解决，但不代表所有底层状态都完全恢复到了正常水平。当你执行建表这类DDL操作时，主库需要和副本完成日志同步，如果副本在升级后残留了一些未修复的问题（比如日志缓存异常、线程池资源未完全释放），就可能导致主库的同步进程陷入循环重试或卡死，进而占用大量CPU资源，最终拖垮整个实例。

我之前确实遇到过类似的案例：有用户在Azure SQL平台维护后执行DDL操作，出现了副本同步延迟飙升、主库CPU异常占满的情况，排查后发现是维护过程中副本的日志读取线程出现了死锁，导致主库一直在重试同步操作，直接把CPU拉满了。

给你几个后续排查的方向：

• 查看数据库的错误日志（Error Log），重点关注建表时间段前后，有没有关于可用性组同步、死锁、资源耗尽的报错信息
• 检查相关性能计数器，比如SQL Server:Availability Replica下的Log Send Queue Size、Redo Queue Size，还有SQL Server:General Statistics里的User Connections、Processes Blocked指标，看看建表操作执行时副本的同步状态
• 回顾平台升级后的资源状态波动，比如副本的CPU、内存使用率有没有异常起伏，有没有出现过短暂的离线或者角色切换记录

另外，你提到强制扩容后问题恢复，这是因为扩容操作会触发实例的资源重新分配，相当于重置了底层的进程和连接，把卡住的同步进程给清理掉了——这也从侧面说明问题大概率出在底层的进程或资源锁上，而不是建表脚本本身（毕竟最终脚本执行完成，新表也成功创建了）。

如果之后再遇到类似情况，若业务允许的话，建议先尝试重启数据库，比强制扩容的影响要小一些；同时及时提交Azure支持工单，让微软工程师帮忙排查底层平台日志，因为有些维护后的隐性问题只有他们能获取到相关信息。

备注：内容来源于stack exchange，提问作者Shawn Clark