Azure SQL Managed Instance 新能力解析：迁移与现代化再加速

在 Azure SQL 家族中，SQL Managed Instance（SQL MI）一直是一个独特的存在——它既不像 SQL Server on Azure VM 那样将整个操作系统交给客户管理，也不像 Azure SQL Database 那样为极致弹性而生，而是以「几乎完整的 SQL Server 兼容性 + 托管服务」的定位，承接了大量企业从本地迁移上云的需求。在近期一场由微软 SQL 团队 Group Product Manager Borko Novakovic 主讲的技术分享中，SQL MI 的多项新能力被系统性地串联成一条从迁移、资源调优到应用现代化的完整路径。

迁移方式的选择：没有银弹，但有了更多在线路径

Novakovic 在开场即强调：没有任何一种迁移方式适合所有场景。选择取决于源端环境、目标端配置，以及应用能容忍多长的中断时间。离线备份还原在变更窗口充足时依然有效，但对于可用性要求高的系统，SQL MI 提供了多条在线迁移路径，包括 Managed Instance Link（MI Link）和 Log Replay Service，以及自动化工具和手动控制方案。

Novakovic 展示了 SQL MI 在线迁移选项的对比，MI Link 在灵活性和最小化停机时间方面表现突出。

MI Link 的独特性在于它不是一次性的数据搬运，而是让源端 SQL Server 和目标端 MI 在一段时间内协同工作。它支持本地部署、Azure VM 以及其它云环境中的 SQL Server，通过近实时复制将数据同步到 Azure，同时源端继续对外提供服务。这意味着在正式切换之前，团队就可以利用 Azure 侧的能力进行只读查询或测试，从而把「迁移」从一个时间点拉长为一个可规划的周期。

更值得关注的是，MI Link 最新扩展了对现有可用性组（Availability Group）多数据库的支持。此前迁移通常以单个数据库为单位，但许多企业应用本身就运行在包含多个数据库的 Always On 可用性组上。新能力允许整个可用性组参与 MI Link 迁移，显著扩大了可适用最小停机迁移的工作负载范围，尤其是关键业务系统。

在演示环节，Novakovic 通过 SMS 18.1.2 的向导完成了从建立链接、种子数据同步到最终故障转移的全流程。他有意将演示拆分为「建立链接」和「执行切换」两步，原因是：在两步之间，团队可以按自己的节奏测试数据、验证应用，而不必被迁移窗口倒逼。切换时复制模式会切换为同步模式，确保 LSN 对齐后再执行故障转移，之后应用连接串重定向即可完成上云。对于 SQL Server 2022 和 2025 的受支持配置，MI Link 还提供了回退能力，这在迁移风险控制上是一个重要的安全垫。

Managed Instance Link（MI Link） 是微软为 SQL Server 到 Azure SQL Managed Instance 迁移提供的一种近实时复制技术。它基于分布式可用性组（Distributed Availability Group）机制实现，在源端 SQL Server 和目标端 MI 之间建立持续的数据同步链路。与传统的日志传送或备份还原不同，MI Link 允许源端数据库在迁移准备期间继续对外提供服务，同时将变更持续复制到 Azure 端，从而将迁移停机时间压缩到仅最终的故障转移切换阶段。该技术支持 SQL Server 2016 及以上版本，覆盖本地、Azure VM 及其他云环境。

Log Replay Service 是另一种在线迁移选项，主要面向 Azure SQL Managed Instance 从 Azure Blob 存储还原备份文件的场景。它通过持续还原日志备份来实现接近实时的数据同步，适用于无法直接建立网络链路的环境。与 MI Link 相比，Log Replay Service 的延迟通常更高，且不支持双向协同工作模式，但在网络隔离或跨云限制较多的场景中仍是有效补充。

成本与性能的再平衡：Next-Gen General Purpose 的实质提升

迁移之后，如何以合理成本运行工作负载是第二个核心议题。SQL MI 的 Next-Gen General Purpose 服务层级已正式可用，Novakovic 建议将其作为大多数工作负载评估的起点。

与旧版相比，Next-Gen GP 的变化不是单点优化，而是存储与计算资源模型的整体调整：存储性能配额从按文件模型转为实例级模型，延迟、IOPS 和日志吞吐量均有改善；单实例最大数据库数从 100 提升到 500，最大存储从 16 TB 翻倍至 32 TB；计算侧提供更多规格选择，使容量与实际需求更精确地匹配。Novakovic 给出的整体画像是：典型场景下 3 到 5 倍的性能提升、最高 5 倍的密度提升、存储规模翻倍、计算弹性翻倍，以及日志性能约三倍的改善。

这些数字背后有一个更实际的决策逻辑：先评估 Next-Gen GP，再按工作负载实际需求选规格，而不是按峰值预留资源。

在 Business Critical 层级，日志吞吐量的提升同样值得注意：Standard 系列上限从 96 MB/s 提升到 160 MB/s，在 16 vCore 时达到；Premium 系列维持 192 MB/s 的上限，但达到该上限所需的 vCore 从 16 降到 12，相当于减少 25% 的计算资源即可触达同一吞吐天花板。Flexible Memory 则允许在不大幅增加 vCore 的情况下提升内存，这对于内存需求与计算需求不同步增长的 SQL 工作负载来说，提供了更细的调节粒度。

Novakovic 通过 HammerDB 演示了 Next-Gen GP 的 IOPS 动态调整能力。

演示中最直观的一幕是 IOPS 滑块：在 IOPS 设为最低时，IO 密集型工作负载的吞吐停留在约 7000 事务/分钟；将 IOPS 滑块拉满并应用后，实例在线更新，无需维护窗口、无需重启、连接零中断，吞吐在数秒内跃升至 70000 事务/分钟以上，并稳定维持。这个 10 倍提升完全来自存储 IOPS 的独立调节，不涉及 vCore 或预留存储的增加。

General Purpose 与 Business Critical 服务层级是 Azure SQL Managed Instance 的两种核心架构。General Purpose 采用远程存储（Azure Premium SSD 或 Ultra Disk），计算与存储分离，适合大多数通用工作负载，成本较低但 IO 延迟相对较高。Business Critical 则采用本地 SSD 存储并内置 Always On 可用性组副本，提供最低的 IO 延迟和最高的可用性保障，适合对性能和韧性要求严苛的关键业务。Next-Gen General Purpose 是在原有 GP 架构上的重大升级，核心变化在于将存储性能配额从按文件分配改为实例级统一池化，使 IOPS、吞吐量和延迟不再受单个数据库文件数量或大小的限制，从而显著提升了资源利用效率和性能上限。

迁移之后：更新策略与现代化路线图

第三个支柱回答的是「上云之后还能做什么」。Novakovic 列举了 Azure SQL 平台上可供增量采用的现代化能力：向量与 AI 能力支持嵌入和语义搜索；JSON 支持处理非传统关系模型的数据；Change Event Streaming 支持实时消费变更、构建事件驱动架构；Data API Builder 通过 REST 或 GraphQL 协议暴露数据。

Novakovic 在讲解现代化能力时展示的 Data API Builder 示意图，它是众多可选增量能力之一。

这些能力可以按需叠加在已迁移的数据库之上，而不要求一次性重构应用。与之一同出现的还有一个容易被忽视但影响深远的开关：更新策略（Update Policy）。选择 Always up-to-date 可以最快获得 Azure 侧的新引擎特性，但数据库格式可能发生分叉，从而失去备份还原和物理复制回 SQL Server 的退出路径（导出导入、事务复制等数据拷贝机制仍然可用）。选择 SQL Server 2022 或 2025 策略则保持与对应引擎版本的对齐，保留相应的可移植性选项，同时仍能获得安全修复、性能改进和 Azure 平台生态的更新。Novakovic 的建议很明确：根据应用路线图和迁移回退需求来选择，而不是默认选最新。

Novakovic 将整条路径总结为四个可执行步骤：优先评估 Next-Gen GP 并选对实例规格；选择匹配可用性要求的迁移方式，在线迁移重点考虑 MI Link（含新支持的多数据库可用性组）；运行后按实际瓶颈独立调节 IOPS、内存或计算资源；在有区域韧性需求时考虑区域冗余。这些步骤不必作为一个项目一次完成——第一步为下一步留下可信的路径，才是这套方法论的关键。对于希望先验证再投入的团队，SQL MI 提供 12 个月免费试用额度，实例不用时停机可保留每月计算配额。

整体来看，SQL MI 这一轮更新的主线并非某个单点功能，而是把「迁移」和「现代化」解耦：先以低门槛完成上云，再按优先级逐步释放平台能力。对于仍在规划 SQL Server 迁移的企业而言，这种可拆分的节奏，可能比任何单项性能数字都更有决策参考价值。

更新策略（Update Policy） 是 Azure SQL Managed Instance 中控制引擎版本演进节奏的配置项。选择 Always up-to-date 意味着实例会自动接收 Azure SQL 引擎的最新功能更新，数据库格式可能随版本升级而分叉，导致无法通过备份还原或物理复制方式回到 SQL Server。选择 SQL Server 2022 或 2025 策略则将引擎版本锁定在与对应本地版本对齐的状态，保留备份还原和物理复制回 SQL Server 的退出路径，同时仍会获得安全补丁和部分性能改进。这一策略在实例创建后可以修改，但修改方向有限制，因此建议在迁移规划阶段就根据应用路线图和回退需求做出决策。

Change Event Streaming 是 Azure SQL 平台上的一项现代化能力，允许将数据库中的变更事件以流式方式推送到 Azure Event Hubs 等消费端，用于构建事件驱动架构、实时分析管道或缓存失效机制。与传统的变更跟踪或 CDC 相比，它更侧重于高吞吐的实时事件分发，适合需要将数据变更即时同步到下游系统的场景。