SQL Server迁移Azure VM：选型、存储与AI扩展指南

将SQL Server工作负载迁移到Azure虚拟机（VM）并非简单的“ lift-and-shift ”。微软SQL团队首席产品架构师Pam Lahoud在近期分享中详细拆解了迁移的决策逻辑、虚拟机选型策略、存储优化以及迁移后的AI扩展可能性。对于追求控制力与兼容性的企业而言，Azure VM上的SQL Server提供了一条兼顾云优势与本地习惯的路径。

为什么选择SQL Server on Azure VM？

Azure SQL家族提供三个主要目标：SQL Server on Azure VM、Azure SQL Database（含Hyperscale）以及Azure SQL Managed Instance。Pam Lahoud明确表示，Hyperscale是“最现代、云原生”的选择，但并非所有场景都适用。

当客户需要运行SSIS、SSRS或AS等与SQL Server引擎并行的服务，或需要对操作系统和SQL Server设置进行更细粒度控制时，Azure VM成为更合适的落点。它保留了与本地SQL Server完全一致的引擎版本和兼容性，现有技能组合与运维流程可以直接复用。

“你仍然在管理操作系统和SQL Server本身，但我们提供了一系列功能和Azure门户可见性，让管理变得更轻松。”

Azure VM上的SQL Server并非孤立的IaaS实例。平台能够识别出该VM是SQL虚拟机，从而在Azure Backup、Azure Update Manager等服务中心启用SQL专属体验。用户既可以使用SSMS或VS Code插件等熟悉工具，也可以转向更现代的门户管理界面。

Azure SQL Managed Instance（MI） 是Azure SQL家族中介于VM与Database之间的PaaS选项。它提供与SQL Server引擎近乎完全兼容的实例级功能（如SQL Agent、跨数据库查询、CLR），但由微软托管操作系统和补丁，用户无法访问底层OS。当工作负载不需要OS级控制、也不需要并行运行SSIS/SSRS等独立服务时，MI可显著降低运维负担。相比之下，Azure VM保留完整OS访问权限，适合需要安装第三方代理、自定义注册表或使用特定文件系统布局的场景。理解三者的边界——VM提供最大控制力、MI提供实例级兼容性、Database提供最高云原生度——是迁移决策的起点。

虚拟机选型：从E系列到约束核心

Azure提供数百种VM规格，但并非都适合SQL Server。Pam Lahoud将内存优化型系列列为首选，尤其是E系列和M系列。E系列提供8:1甚至更高的内存核心比，而M系列可达20:1，适合大型本地“大铁块”工作负载。

对于部门级或开发测试等较小负载，D系列通用型VM（约4:1内存核心比）足以应对。计算密集型场景中，新一代FXV2和FA系列（AMD平台）专为SQL设计，兼具高计算性能与高内存核心比，适合关键型OLTP。

“EBDS V5是我们的绝对最爱，我们叫它‘双倍撒糖’（double-sprinkler）。这是一款非常非常强大的VM。”

命名规则中的字母含义至关重要：B代表带宽优化（最高IO吞吐），D代表含本地临时盘（适合放置tempdb），S代表支持高级存储。Pam建议SQL工作负载优先关注这三个字母。

约束核心（Constrained Core）VM是成本优化的关键手段。固定约束核心规格（如M32-16）提供M32的内存和吞吐，但仅16核可用，许可仅按16核计费。近期GA的可配置约束核心功能更进一步：用户可在多数VM系列上自定义可用核心数，甚至关闭超线程，仅使用物理核心。

Pam给出的短名单包括：EBDS V5（全能首选）、FXMDS V2（计算优化、默认关闭超线程、近2TB内存）、DDS V7（通用小型负载）、FAMDS V7（计算密集OLTP）以及MBDS V3（大型分析/关键OLTP）。即将推出的EBDS V6（代号“Stardust”）和MBDS V4将进一步提升内存与IOPS。

约束核心（Constrained Core） 是微软针对Windows Server许可成本设计的VM计费模式。在标准VM中，软件许可费用按VM的全部vCPU数计算；而约束核心规格通过固件层面限制可用核心数，使SQL Server和Windows Server许可仅按实际可用核心计费，内存和IO吞吐则保持原规格水平。例如M32-16拥有M32的256GB内存和IO能力，但仅16个核心可用，许可成本减半。对于内存需求高但CPU利用率低的分析型或报表型工作负载，这种模式可在不牺牲内存容量的前提下大幅降低总拥有成本（TCO）。

存储与性能规划：IOPS是迁移盲区

生产环境应选用高级存储。Pam推荐Premium SSD V2作为性价比最优选，其IOPS和吞吐配置灵活，可组合使用。对延迟有极致要求时可选择Ultra Disk。标准SSD和HDD仅适合非关键开发环境。

迁移中常见的盲区是IO需求评估。本地环境通常连接高速SAN，团队很少关注具体IOPS。但在Azure中，VM本身和附加磁盘均有IO上限，必须提前测量工作负载（Windows性能监视器或Linux iostat），再对照文档中的限额选择规格。

手动匹配数百种VM不现实。微软在SSMS 22、Azure Arc和Azure Migrate中内置了评估工具，共享同一套数据库迁移评估代码，可基于功能兼容性和性能数据推荐目标规格。Copilot和SQL AI Skills仓库（aka.ms/MicrosoftSQLSkills）进一步支持评估、规划和迁移验证的智能体化体验。

Premium SSD V2 是Azure为高性能工作负载推出的第二代高级固态盘，与第一代Premium SSD（P系列）的关键区别在于：它不预置固定性能档位，而是允许用户独立调整磁盘容量（GiB）、IOPS和吞吐量（MB/s），且可在不停机的情况下动态修改。这一特性使其特别适合SQL Server工作负载——数据文件、日志文件和tempdb对IOPS与吞吐的需求各不相同，可按磁盘分别调优。此外，Premium SSD V2的每GiB成本低于Ultra Disk，但延迟略高，因此适合需要高IOPS但延迟敏感度中等的场景；Ultra Disk则面向亚毫秒级延迟要求的核心交易系统。

迁移之后：管理平面与AI扩展

进入Azure后，SQL Server仍是那个SQL Server，但周边生态打开了新可能。Azure Backup、Update Manager、Microsoft Entra认证和RBAC提供统一管理平面，且通过Arc可覆盖本地实例。

更值得关注的是数据与AI服务的邻近性。Fabric可镜像SQL Server数据（无论驻留何处），解锁分析能力；Microsoft Foundry结合SQL中的向量索引，可在现有数据上构建智能体体验。

“一旦工作负载进入Azure，即使是在Azure VM上的SQL Server，你能构建的东西几乎没有上限。”

Pam还提到DP-800（Microsoft Certified SQL AI Developer）认证，作为验证Azure SQL与AI能力的路径。对于正在规划迁移的团队，她的核心建议是：从E系列起步，用评估工具量化IO需求，优先Premium SSD V2，并在迁移后将管理交给Azure服务、将创新留给Fabric与Foundry。