做数据库的都知道一个痛点：业务涨了，数据库扛不住了，扩到最大规格还是不够用。
以前 Azure SQL Database Hyperscale 的单库上限是 128 vCore——对大多数场景够用了，但对于那些真正"重量级"的工作负载（比如大型电商的 OLTP、金融交易系统、HTAP 混合负载），128 核有时候就是天花板。
3 月 18 日，微软正式宣布突破这个天花板。
🚀 核心更新：160 和 192vCore 正式进入公测
Azure SQL Hyperscale 在 Premium-series 硬件配置下新增两个计算规格：
| 规格 | 定位 | 适用场景 | |------|------|----------| | 160 vCore | 性能与成本的平衡点 | 单查询 + 并发性能兼顾的场景 | | 192 vCore | 极致吞吐量 | 高并发用户、大规模事务/分析混合负载 |
这意味着什么？单库最大规模从 128 vCore 直接拉到 192 vCore，提升了 50%。 而且不需要改应用代码。
📊 硬规格对比：到底升级了啥？
单数据库资源限制
| 指标 | 128 vCore（当前） | 160 vCore（公测） | 192 vCore（公测） | |------|-------------------|-------------------|-------------------| | 内存 | 625 GB | 830 GB | 843 GB* | | Tempdb 上限 | 4,096 GB | 4,096 GB | 4,096 GB | | 本地 SSD 最大 IOPS | 544,000 | 680,000 | 816,000 | | 日志写入速率 | 150 MiB/s | 150 MiB/s | 150 MiB/s | | 最大并发工作线程 | 12,800 | 16,000 | 19,200 | | 最大并发会话数 | 30,000 | 30,000 | 30,000 |
弹性池资源限制
| 指标 | 128 vCore | 160 vCore | 192 vCore | |------|----------|----------|----------| | 本地 SSD 最大 IOPS | 409,600 | 800,000 | 960,000 | | 池内最大并发线程 | 13,440 | 16,800 | 20,160 |
*注：192 vCore 内存在正式版(GA)时还会进一步提升
关键亮点：
- IOPS 从 54 万提升到 81.6 万（+50%）
- 并发工作线程从 1.28 万提升到 1.92 万（+50%）
- 弹性池的 IOPS 提升更夸张：从 40 万直接到 96 万（+135%）
🔥 性能实测数据：提升有多大？
微软放出了 TPC-H 基准测试数据，说实话结果挺惊艳：
TPC-H Power Run（单流查询性能）
| 规格 | 得分 | 对比 128vCore | |------|------|-------------| | 128 vCore | 217 | 基线 | | 160 vCore | 357 | +64% | | 192 vCore | 355 | +64% |
TPC-H Throughput Run（多流并发性能）
| 规格 | QPH（每小时查询数） | 对比 128vCore | |------|---------------------|-------------| | 128 vCore | 191 | 基线 | | 160 vCore | 360 | +89% | | 192 vCore | 511 | +168% |
注意这个数据！ 单查询场景提升约 64%，但多并发场景直接暴涨 168%。这说明新规格在高并发下的扩展效率远超预期——对于国内很多"高并发读+夜间批量跑批"的混合场景来说，这简直是量身定制。
💡 谁需要关注这个？
适用场景
- 大型 OLTP 系统 — 电商订单、支付核心等高并发事务处理
- HTAP 混合负载 — 同一库上同时跑事务和报表查询（比如用 Power BI 直连生产库做实时分析）
- 高并发 SaaS 平台 — 多租户共享一个大库的场景
- 夜间 ETL 不想影响在线服务 — 更大的计算能力意味着 ETL 完成时间缩短
- 不想拆库/分片的团队 — 以前因为性能瓶颈被迫做 Sharding，现在可能一条 Scale Up 就搞定
真实案例：Zava Lending
Zava Lending 是这次预览版的早期采用者。他们的做法很有代表性：
- 从 32 → 64 → 128 → 192 vCore 一路在线扩容，零停机
- 每次扩容都是在线操作，不需要改应用代码
- 192 vCore 成为他们承载峰值交易量的最佳平衡点
- OLTP + 分析混合负载都能扛住，没有成为瓶颈
这就是云数据库最大的优势：按需弹性伸缩，不用担心硬件采购周期。
⚠️ 公测限制（上线前必看）
毕竟是预览版，有些限制你需要知道：
- 不支持区域冗余（Zone Redundant） — 如果你的业务要求跨可用区高可用，暂时不能用这两个规格
- 不支持维护窗口配置 — 微软默认维护时段，你不能自定义
- 区域有限 — 目前只在以下区域开放（详见下文）
- 192 vCore 的内存值在 GA 后还会调整（大概率是增加）
🌍 可用区域
公测期间支持的区域：
| 区域 | 备注 | |------|------| | Australia East | 澳洲东部 | | Canada Central | 加拿大中部 | | East US 2 | 美东 2 | | South Central US | 美国中南部 | | UK South | 英国南部 | | West Europe | 西欧 | | North Europe | 北欧 | | Southeast Asia | 东南亚（离中国最近） | | West US 2 | 美西 2 |
💡 国内用户注意：目前开放的都是海外区域，没有中国区（Azure China）。 如果你在中国运营且有数据出境合规要求，暂时还用不上。建议持续关注后续是否扩展到中国区。
🆚 与国内云数据库的对比思考
看到这里你可能在想：阿里云 RDS / 腾讯云 CDB 能不能做到这个级别？
简单说几点对比思路：
- 最大规格：阿里云 RDS MySQL/PG 企业版最高可达 104 核，腾讯云 CDB 最高 128 核。Azure SQL 这次 192 核在绝对数值上有优势
- 架构差异：Hyperscale 的存储和计算分离架构让扩缩容特别灵活，这点国内云厂商也在跟进
- 生态集成：如果你已经在用 Power BI、Fabric、Synapse 等 Microsoft 生态，Azure SQL 的集成优势明显
- 成本模型：vCore 按需计费 vs 国内云厂商通常的包年包月模式，不同使用模式成本差异很大，需要根据实际场景算账
- 合规性：金融、政府等行业如果要求数据不出境，国内云厂商是唯一选择
🛠️ 怎么上手？
两种方式启用新规格：
- 新建数据库时 — 选择 Hyperscale 服务层级，Premium-series 硬件，vCore 选 160 或 192
- 已有数据库扩容 — 在支持区域内直接 Scale Up（同样是在线操作）
前提是你的目标区域当前有预览容量可用。
📌 总结：Azure SQL Hyperscale 这次把单库算力上限拉到了 192 vCore，IOPS 提升 50%、并发能力翻倍，多流 TPC-H 测试更是暴涨 168%。对于那些被 128 核卡脖子的大负载场景，这可能是"不用改架构就能续命"的最佳方案。
不过公测阶段限制不少（无区域冗余、仅海外区），国内用户如果有合规要求，建议先观望，等正式版和中国区的消息。
📖 原文链接：https://techcommunity.microsoft.com/t5/azure-sql-blog/announcing-preview-of-160-and-192vcore-premium-series-options/ba-p/4501367 📅 发布日期：2026-03-18
本文由 baiyangbistudio 整理，如需技术咨询，请添加微信 baiyangbistudio
