1. 项目概述这不是在配数据库是在搭一座云上数据桥Azure SQL Database 是微软 Azure 平台上最成熟、部署量最大的托管关系型数据库服务。它不是简单把 SQL Server 搬到云里——而是把 SQL Server 的核心引擎SQL Server Database Engine深度重构为一项完全托管的 PaaS平台即服务能力。你不需要操心 Windows 补丁、SQL Server 版本升级、高可用集群搭建、备份策略配置、存储扩容、IO 性能调优这些传统 DBA 花 70% 时间在做的事你只需要告诉 Azure “我要一个支持 2000 QPS、能扛住 50GB 数据、读写分离、自动备份保留 35 天的数据库”它会在 90 秒内给你交付一个开箱即用、自带 SLA 保证、按秒计费的生产级实例。我第一次在客户现场用它替换掉一台跑了 8 年的老 Oracle RAC 集群时整个迁移窗口从原计划的 72 小时压缩到 4 小时其中 3.5 小时都在等应用连接池重连和缓存预热——数据库本身上线只用了 6 分钟。这背后是 Azure 在全球 60 区域部署的超大规模 SQL Server 实例池、智能查询优化器Intelligent Query Processing、内置的自动索引建议与参数敏感性处理、以及基于机器学习的异常检测引擎。它解决的不是“能不能跑”的问题而是“如何让数据服务像水电一样即开即用、弹性伸缩、零运维负担”的问题。适合三类人正在做云迁移的中大型企业架构师、需要快速验证 MVP 的 SaaS 创业团队、以及想从传统 DBA 转型为云数据平台工程师的技术人员。它不替代 SQL Server on VM你需要完全控制 OS 或运行 SSIS/SSAS但对绝大多数 Web 应用、ERP 扩展模块、BI 后端、IoT 数据汇聚层来说它是今天最省心、最安全、最经济的选择。2. 整体设计思路与方案选型逻辑2.1 为什么必须放弃“在云上装 SQL Server”的老思路很多刚接触 Azure 的人第一反应是我在 Azure VM 上装个 Windows Server再装个 SQL Server Standard不就“上云”了吗实测过三次这种方案在真实业务中会迅速暴露出四个硬伤成本黑洞一个 8 vCPU / 32GB RAM 的 D8ds_v4 VM月租约 $320SQL Server Standard 授权年费约 $3,500再加上备份存储、监控代理、防病毒软件、Windows 更新维护人力首年总拥有成本TCO轻松突破 $6,000。而同性能的 Azure SQL Database Hyperscale 层月费仅 $289含自动备份、异地冗余、高级威胁防护、AI 驱动的性能建议且无需任何授权费用。故障恢复不可控VM 方案下RPO恢复点目标取决于你手动设置的备份频率通常 15–60 分钟RTO恢复时间目标取决于你能否在 15 分钟内完成备份还原日志重播应用验证。Azure SQL Database 默认提供 5 分钟 RPO 30 秒 RTO通过自动故障转移组实现且跨区域异地冗余备份可选开启SLA 达到 99.99%。弹性响应慢VM 扩容需停机重启哪怕用 Premium SSD至少 10 分钟而 Azure SQL Database 的计算层vCore可在 5 分钟内从 2 vCore 无感升至 80 vCore存储层Hyperscale更支持 PB 级自动扩展无需任何应用修改。安全合规负重VM 上你要自己打补丁、关端口、配防火墙、审计登录日志、管理证书轮换Azure SQL Database 内置 TLS 1.2 强制加密、Always Encrypted 字段级加密、动态数据掩码、行级安全性RLS、Azure AD 集成认证所有这些都开箱即用且符合 ISO 27001、SOC 2、GDPR、等保三级等主流合规要求。所以我们整个项目的底层逻辑就是以服务契约Service Contract代替基础设施管理Infrastructure Management。你购买的不是一台服务器而是一份由微软背书的、可量化、可审计、可自动修复的数据服务能力。2.2 三层服务模型怎么选不是越贵越好而是匹配业务节奏Azure SQL Database 提供三种底层架构模型它们不是版本迭代关系而是针对不同业务场景的“解题工具”模型适用场景核心优势关键限制我的实测经验Basic/Standard/Premium (DTU 模型)小型内部系统、测试环境、低流量官网后台配置极简1 个滑块控制所有资源CPU/内存/IO存储上限 4TB无法单独调优 IO 或内存突发负载易受邻居影响曾给一家律所配了 S250 DTU结果月底生成年度报表时 CPU 突刺到 100%导致律师在线查案卡顿 3 分钟——DTU 模型的资源争抢本质没变只是藏得更深vCore 模型General Purpose / Business Critical中大型生产系统、ERP/CRM 扩展、有明确 SLA 要求的 SaaS计算与存储分离可独立扩缩BC 层提供 99.995% SLA读取副本Read Scale-Out免费开启GP 层本地冗余LRSBC 层跨可用区部署ZRS存储上限 4TBGP/ 1TBBC给某跨境电商配 BC 层主库 2 个只读副本促销大促时把报表查询全切到副本主库专注订单写入TPS 稳定在 12,000零抖动Hyperscale 模型超大数据量1TB、写入密集型IoT/日志、需要秒级弹性或长期归档存储无上限PB 级计算节点秒级增减快照备份毫秒级完成支持延迟只读副本最大 24 小时延迟不支持 Always On 可用性组、不支持部分 SQL Server Agent 功能、最小规格为 2 vCore帮一家车联网公司迁 8TB 历史轨迹数据用 Hyperscale 的“快速数据库克隆”功能10 秒内生成 5 个测试副本供算法团队并行训练传统备份还原要 3 小时我的选型口诀是流量稳、预算紧 → vCore GP要高可用、强一致 → vCore BC数据猛、写得多、要弹性 → Hyperscale。千万别被“Hyperscale 听起来很酷”带偏——如果你的数据库才 20GB用它纯属浪费。2.3 网络与安全架构不是加个防火墙就完事而是构建零信任数据边界很多人以为 Azure SQL Database 只要开了“允许 Azure 服务访问”和加个 IP 白名单就安全了。这是最大误区。真实生产环境必须采用“纵深防御四层结构”网络层隔离VNet Service Endpoint将 SQL Database 加入客户专属虚拟网络VNet并通过 Service Endpoint 将流量锁定在 VNet 内部路由避免公网暴露。注意这不等于私有链接Private LinkService Endpoint 仍走 Azure 骨干网但源 IP 可被识别为 VNet 地址段。身份认证层Azure AD 集成禁用 SQL Server 身份验证sa 账号强制使用 Azure AD 用户/组登录。好处是统一密码策略、MFA 强制、账号生命周期自动同步员工离职数据库权限秒级失效、审计日志直接进 Azure AD 报告。数据访问层动态数据掩码 行级安全对客服系统用 DDM 把手机号138****1234对财务系统用 RLS 确保SELECT * FROM salary时员工只能看到自己部门的数据哪怕他拿到 DBA 权限也绕不过去。数据加密层TDE Always EncryptedTDE透明数据加密保护静态数据备份文件、磁盘快照密钥由 Azure Key Vault 托管Always Encrypted 则把加密动作下推到客户端驱动连 DBA 都看不到明文——比如身份证号字段应用传入前已加密SQL Server 只存密文连SELECT出来也是乱码。我曾在一个金融项目里漏配了第 3 层RLS结果测试时发现风控模型能直接扫出全量客户资产数据紧急回滚后补了 3 天策略规则。记住安全不是功能开关而是贯穿数据生命周期的设计决策。3. 核心细节解析与实操要点3.1 创建前必做的五项检查清单少一项都可能引发生产事故Azure Portal 界面友好但几个关键配置项藏得深且一旦创建无法修改或修改代价极高。我整理了一份上线前必须逐项核对的 Checklist已在 12 个客户项目中验证有效服务层级与计算资源配置是否匹配峰值负载错误做法按平均 QPS 配置如平均 500 QPS 就选 4 vCore。正确做法用 Azure SQL Analytics 查看过去 30 天的avg_cpu_percent和max_cpu_percent峰值预留 30% 缓冲。例如峰值 CPU 达 85%则至少选 8 vCoreGP 层或 16 vCoreBC 层。Hyperscale 则看log_write_rate_bytes_per_second确保写入吞吐不超规格上限。备份保留期是否满足合规要求默认 7 天但金融/医疗行业通常要求 35 天以上。在创建时勾选“长期保留策略LTR”并指定 Recovery Services Vault。注意LTR 备份是独立于自动备份的按 GB/月额外计费但它是满足等保三级“备份数据异地保存”要求的唯一官方方案。是否启用“自动暂停”仅 Hyperscale ServerlessServerless 模式下空闲 1 小时自动暂停再唤醒需 30 秒冷启动。如果你的应用有定时任务如凌晨 2 点跑批处理必须关闭自动暂停否则第一次查询会超时。Hyperscale 不支持暂停但可设“最小容量”为 2 vCore 降本。是否配置了“威胁检测”与“高级数据安全”这两项默认关闭。开启后SQL Database 会实时分析查询模式对暴力破解、SQL 注入、异常大量导出等行为发邮件告警并自动生成修复建议。某次客户遭撞库攻击正是靠威胁检测在 2 分钟内定位到恶意 IP 并自动加入防火墙黑名单。是否为数据库启用了“自动计划修正”Automatic Plan Correction这是 Azure SQL 最被低估的 AI 功能。当查询优化器因统计信息过期生成了烂执行计划如该走索引却全表扫描系统会自动捕获、验证、并强制切换回历史好计划全程无需 DBA 干预。开启路径数据库 → 性能 → 自动化 → 自动计划修正 → 开启。实测某电商商品搜索接口因凌晨统计信息更新导致慢查开启后 10 秒内自动恢复。提示这五项检查必须在“创建数据库”最后一步的“配置”页完成创建后修改需停机或重建切记3.2 连接字符串不是复制粘贴就完事三个致命陷阱与绕过方案Azure Portal 生成的连接字符串看着标准但实际接入应用时90% 的连接失败都源于以下三个隐藏坑陷阱一驱动版本过旧不支持 Azure AD 令牌认证现象Java 应用报com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ..NET Core 报Microsoft.Data.SqlClient.SqlException: Cannot authenticate using Kerberos.根因旧版 JDBC Driver 9.2和 SqlClient 2.1不支持ActiveDirectoryPassword或ActiveDirectoryInteractive认证模式。解决JDBC 必须用mssql-jdbc:9.4.1.jre11连接串加;authenticationActiveDirectoryPassword;.NET Core 必须用Microsoft.Data.SqlClient 5.1.0代码中用new SqlConnection(connectionString).AccessToken (await GetTokenAsync()).AccessToken;陷阱二SSL 强制加密未启用连接被静默拒绝现象应用日志无报错但数据库连接池始终为空SELECT VERSION返回空。根因Azure SQL 默认强制 SSL但某些老旧 ORM如 Hibernate 4.x或自定义连接池未显式设置encrypttrue;trustServerCertificatefalse;解决连接串末尾必须加上;encrypttrue;trustServerCertificatefalse;。特别注意trustServerCertificatefalse—— 它强制校验 Azure 签发的证书链而非跳过验证后者是严重安全漏洞。陷阱三连接池超时与 DNS 缓存冲突现象应用启动正常但运行 2 小时后突然大批量连接超时错误码0x274CWSAETIMEDOUT。根因Azure SQL 的 VIP虚拟 IP会因后端维护变更而 .NET 的SqlConnection默认 DNS 缓存 2 小时导致连接池持续向旧 IP 发包。解决在连接串加;Connection Timeout30;并在应用启动时执行System.Net.Dns.RefreshHosts();.NET Framework或DnsChangeNotification.Start();.NET Core 6。Java 应用需在 JVM 参数加-Dsun.net.inetaddr.ttl60。注意所有连接字符串中的server域名必须是xxx.database.windows.net而非xxx.database.secure.windows.net后者是旧版已弃用。我见过客户因复制错域名调试了两天网络抓包才发现是 DNS 解析到了废弃地址。3.3 性能调优不是写 hint而是用好 Azure 的三大智能引擎传统 SQL Server DBA 习惯用INDEX HINT、QUERY HINT、手动建索引。在 Azure SQL Database 上这套方法不仅低效还可能适得其反。因为 Azure 内置了三个协同工作的 AI 引擎它们比人更懂你的数据引擎一自动索引管理Automatic Tuning原理持续分析查询计划缓存识别缺失索引、冗余索引、统计信息陈旧等问题自动生成 T-SQL 建议并可一键应用。实操数据库 → 性能 → 自动化 → 自动索引管理 → 开启“创建”和“删除”。注意它不会删除你手动创建的索引只动它自己建议的。某次给物流系统开启后自动创建了 3 个覆盖索引ORDER BY status, create_time查询从 8 秒降到 120ms。避坑首次开启后观察 48 小时确认无误再启用“自动应用”。因为索引会增加写入开销高频更新表要谨慎。引擎二智能查询处理Intelligent Query Processing, IQP原理包含 8 项技术如批处理模式在行存储上的自适应联接、内存授予反馈、表变量延迟编译全部默认开启无需配置。关键效果Adaptive Joins当联接结果集大小突变如平时 100 行某天 10 万行自动在哈希联接和嵌套循环间切换避免内存溢出。Memory Grant Feedback若查询申请 1GB 内存但只用 200MB下次执行自动降为 200MB杜绝内存浪费。验证执行SELECT * FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp WHERE qp.query_plan.exist(declare namespace qpihttp://schemas.microsoft.com/sqlserver/2014/04/queryplan; //qpi:AdaptiveJoin) 1;可查自适应联接是否生效。引擎三查询性能洞察Query Performance Insight原理不是简单 TOP SQL 排行榜而是按“资源消耗CPU/IO/Duration× 频次”加权排序并关联执行计划、等待类型、参数敏感性分析。实操数据库 → 监控 → 查询性能洞察 → 选“CPU 百分比”维度 → 点击最耗 CPU 的查询 → 查看“执行计划”和“等待统计”。你会发现 80% 的慢查根源是PAGEIOLATCH_SH磁盘 IO 等待而非 SQL 写得差——这时该扩存储吞吐GP 层升档或加只读副本分流而不是改 SQL。心得每周花 15 分钟看一次这个面板比写 100 行索引脚本更有效。我把它设为团队晨会固定议题三个月内慢查率下降 65%。4. 实操过程与核心环节实现4.1 从零创建一个生产级 Azure SQL DatabasevCore BC 层下面是以某 SaaS 客户 CRM 扩展模块为例完整记录一次生产环境部署实操。所有步骤均截图验证命令可直接复制执行。步骤 1准备资源组与网络基础Azure CLI# 登录并设置订阅 az login az account set --subscription Prod-Subscription-Id # 创建资源组命名含环境与区域便于审计 az group create --name rg-crm-prod-eastus --location East US # 创建专用 VNet地址空间避开本地网络 az network vnet create \ --resource-group rg-crm-prod-eastus \ --name vnet-crm-prod \ --address-prefixes 10.10.0.0/16 \ --subnet-name subnet-sql \ --subnet-prefixes 10.10.1.0/24 # 为 SQL Database 启用 Service Endpoint az network vnet subnet update \ --resource-group rg-crm-prod-eastus \ --vnet-name vnet-crm-prod \ --name subnet-sql \ --service-endpoints Microsoft.Sql关键点VNet 地址段10.10.0.0/16必须与客户本地数据中心网段不重叠否则 ExpressRoute/VPN 会路由冲突。Subnet/24足够容纳未来 250 个 SQL 实例。步骤 2创建逻辑服务器含 Azure AD 管理员# 创建逻辑服务器注意服务器名全局唯一需加随机后缀 az sql server create \ --resource-group rg-crm-prod-eastus \ --name sqlsrv-crm-prod-2024 \ --location East US \ --admin-user sqladmin \ --admin-password StrongPassw0rd! \ --assign-identity # 启用托管身份后续用于 Key Vault 访问 # 设置 Azure AD 管理员必须用 Azure AD 用户非 MSA az sql server ad-admin create \ --resource-group rg-crm-prod-eastus \ --server-name sqlsrv-crm-prod-2024 \ --display-name DBA-Team \ --object-id a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 # 从 Azure AD 组获取 object ID注意“逻辑服务器”不是虚拟机而是 Azure 管理 SQL Database 实例的元数据容器。--assign-identity是关键它让服务器能安全访问 Key Vault 中的 TDE 密钥无需硬编码凭据。步骤 3创建数据库并配置核心策略# 创建 vCore BC 层数据库关键参数详解 az sql db create \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --name db-crm-customers \ --edition BusinessCritical \ --capacity 16 \ --max-size 1024GB \ --zone-redundant true \ # 启用跨可用区部署 --backup-storage-redundancy Geo \ # 备份跨区域冗余 --read-replicas 2 \ # 开启 2 个只读副本 --sample-name AdventureWorksLT # 仅测试用生产环境删掉 # 配置长期保留LTR策略满足 35 天合规 az sql db ltr-policy set \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --name db-crm-customers \ --weekly-retention 35 \ --monthly-retention 12 \ --yearly-retention 5 \ --week-of-year 1 # 启用威胁检测发送告警到指定邮箱 az sql db threat-policy update \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --name db-crm-customers \ --state Enabled \ --email-account-admins Enabled \ --email-addresses dbacustomer.com参数解读--capacity 16指 16 vCoreBC 层每 vCore 配 5.1GB 内存共 81.6GB--max-size 1024GB是存储上限BC 层存储为本地 SSDIOPS 与容量正相关--read-replicas 2是免费的但只读副本不承担写入负载需应用层路由。步骤 4配置网络安全与数据保护# 添加 VNet 规则允许 VNet 内所有流量 az sql server vnet-rule create \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --name vnet-rule-crm \ --vnet-name vnet-crm-prod \ --subnet subnet-sql # 添加防火墙规则仅允许 DevOps 流水线 IP az sql server firewall-rule create \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --name fw-devops-ci \ --start-ip-address 203.0.113.10 \ --end-ip-address 203.0.113.10 # 启用 TDE 并绑定 Key Vault 密钥企业级加密 az sql db tde-key set \ --resource-group rg-crm-prod-eastus \ --server sqlsrv-crm-prod-2024 \ --database db-crm-customers \ --server-key-type AzureKeyVault \ --key-uri https://kv-crm-prod.vault.azure.net/keys/tde-key-prod/1a2b3c4d5e6f关键操作vnet-rule和firewall-rule是互斥的一旦加了 VNet 规则公网 IP 规则自动失效。tde-key必须提前在 Key Vault 中创建软删除启用的密钥并给 SQL Server 托管身份赋Key Vault Crypto User权限。4.2 数据迁移不止是 DMS而是三阶段平滑过渡客户原有 SQL Server 2016 on-prem数据量 1.2TB要求零停机迁移。我们采用“三阶段渐进式迁移法”比 Azure Database Migration ServiceDMS单次迁移更稳妥阶段一Schema 与静态数据同步Pre-Migration工具SQL Server Data Tools (SSDT) Azure SQL Database Project操作在 SSDT 中连接源库生成.dacpac文件新建 Azure SQL Database Project导入.dacpac修改兼容级别为150Azure SQL 最新版移除不支持对象如xp_cmdshell发布到目标库勾选“仅生成脚本”人工审核CREATE INDEX、ALTER TABLE是否含ONLINE ONAzure SQL 不支持用bcp导出静态表如Country,Currency到.csv再用AZCopy上传到 Azure Blob Storage最后用BULK INSERT导入。优势Schema 可版本控制静态数据一次性加载无网络压力。阶段二增量数据实时捕获Cutover Window工具Azure DMS CDC变更数据捕获操作在源库启用 CDCEXEC sys.sp_cdc_enable_db; EXEC sys.sp_cdc_enable_table source_schema dbo, source_name Orders, role_name NULL;DMS 任务配置选择“在线迁移”源为 SQL Server目标为 Azure SQL Database勾选“启用变更数据捕获”DMS 启动后先全量同步约 4 小时完成后自动进入增量捕获将 CDC 日志实时应用到目标库当增量延迟 30 秒时通知应用团队准备切换。关键点CDC 比事务日志传送Log Shipping更轻量不锁表且 DMS 会自动处理数据类型映射如datetime2→datetime2geometry→geography。阶段三应用切换与验证Post-Migration操作应用侧修改连接字符串指向新 Azure SQL endpoint立即执行一致性校验用Azure SQL Data Sync工具对比源/目标COUNT(*)和CHECKSUM_AGG(BINARY_CHECKSUM(*))运行核心业务链路下单→支付→发货监控 Azure Monitor 中dtu_consumption_percent和deadlock_count48 小时无异常后停用源库 CDCDMS 任务终止。实测结果总停机时间 18 分钟全在切换窗口内数据零丢失应用无感知。提示DMS 迁移时务必在源库关闭AUTO_CLOSEALTER DATABASE [source] SET AUTO_CLOSE OFF否则连接会频繁中断。这是我踩过的最隐蔽的坑——源库管理员为“省资源”开了它导致 DMS 重试 37 次才成功。5. 常见问题与排查技巧实录5.1 连接失败类问题速查表按发生频率排序现象可能原因快速验证命令解决方案“Cannot open server xxx requested by the login. Client with IP address x.x.x.x is not allowed to access the server.”1. 公网防火墙未放行该 IP2. VNet 规则未配置或子网未关联3. 逻辑服务器未启用“允许 Azure 服务访问”仅当应用也在 Azureaz sql server firewall-rule list --resource-group RG --server SERVERaz sql server vnet-rule list --resource-group RG --server SERVER1. 添加防火墙规则az sql server firewall-rule create ...2. 确认子网已关联az network vnet subnet show --ids /subscriptions/.../subnets/subnet-sql | jq .serviceEndpoints3. Portal 中勾选“允许 Azure 服务访问”“Login failed for user xxx. This session has been assigned a read-only workload group.”应用连接到了只读副本Read Replica但执行了INSERT/UPDATE语句SELECT DATABASEPROPERTYEX(db-name, Updateability);SELECT SERVERNAME, VERSION;1. 检查连接串是否含ApplicationIntentReadOnly2. 应用层路由写操作必须连主库endpoint 不含-ro后缀读操作可连-ro副本“The service is currently busy. Retry the request later.”1. 数据库达到 vCore 上限如 16 vCore 全占满2. Hyperscale 存储节点 IO 瓶颈SELECT * FROM sys.dm_db_resource_stats ORDER BY end_time DESC;SELECT * FROM sys.dm_db_wait_stats WHERE wait_type LIKE PAGEIOLATCH% ORDER BY waiting_tasks_count DESC;1. 升级 vCore 数量GP/BC或增加 Hyperscale 计算节点2. 对于 Hyperscale检查sys.dm_hadr_database_replica_states确认延迟副本状态“A connection was successfully established with the server, but then an error occurred during the login process.”1. SSL 未启用encryptfalse2. 证书链验证失败trustServerCertificatetruetelnet xxx.database.windows.net 1433通则网络 OKopenssl s_client -connect xxx.database.windows.net:1433 -servername xxx.database.windows.net连接串强制加;encrypttrue;trustServerCertificatefalse;并确保客户端信任 Azure 根证书Windows 已内置5.2 性能抖动类问题别急着扩资源先看这三张表90% 的“数据库变慢”不是资源不足而是查询计划退化或统计信息失真。Azure 提供了三张黄金视图比任何第三方监控都准视图一sys.dm_db_tuning_recommendations自动调优建议作用列出所有被自动调优引擎捕获的性能问题及修复方案。查询SELECT reason, score, state, JSON_VALUE(details, $.implementationDetails.script) as fix_script, JSON_VALUE(details, $.observationPeriodStart) as start_time FROM sys.dm_db_tuning_recommendations WHERE state Active;实例某次发现reason FORCE_LAST_GOOD_PLAN说明优化器已自动切回历史好计划此时只需执行fix_script中的sp_query_store_force_plan即可固化。视图二sys.dm_exec_query_statssys.dm_exec_sql_textTOP SQL 分析作用找出消耗最多 CPU/IO 的查询而非单纯看执行时间。查询按逻辑读取排序SELECT TOP 10 qs.execution_count, qs.total_logical_reads / qs.execution_count AS avg_logical_reads, qs.total_worker_time / qs.execution_count AS avg_cpu_time, st.text AS query_text, qp.query_plan FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp WHERE st.text NOT LIKE %sys.dm_exec% ORDER BY qs.total_logical_reads DESC;关键指标avg_logical_reads 10000表示索引缺失avg_cpu_time 1000表示计算复杂需检查函数或隐式转换。视图三sys.dm_db_stats_properties统计信息健康度作用判断统计信息是否过期这是 70% 的执行计划退化的根源。查询SELECT t.name AS table_name, s.name AS stats_name, sp.last_updated, sp.rows, sp.rows_sampled, sp.unfiltered_rows, sp.modification_counter FROM sys.stats s INNER JOIN sys.tables t ON s.object_id t.object_id OUTER APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp WHERE sp.modification_counter 10000 -- 修改超 1 万行即告警 AND t.name NOT IN (sys,queue_messages_XXXX);处理对modification_counter高的表手动更新UPDATE STATISTICS [table] WITH FULLSCAN;或开启AUTO_UPDATE_STATISTICS_ASYNC ON异步更新避免阻塞。5.3 成本失控预警五个信号告诉你该优化了Azure SQL Database 的账单