1. 迁移升级全景概览

SQL Server 大型数据库的迁移升级，从来不是“把备份还原到新实例”这么简单。当数据库规模达到数 TB、承载核心交易、停机窗口只有几小时、上下游系统几十个时，迁移就变成一项需要架构设计、风险控制与工程化执行并重的系统性工程。本节先建立一张全景地图：看清典型场景、识别核心挑战、抓住关键成功要素，并给出一套可落地的整体方法论。

一、典型场景：先判断“为什么迁”

不同驱动力决定了迁移的技术路线与风险优先级。常见场景可归纳为四类：

• 版本升级：如 SQL Server 2012/2016 升级到 2019/2022，主要动因是微软停止主流支持、需要新特性（如智能查询处理、加速数据库恢复 ADR）或合规要求。核心矛盾是兼容性，而非数据搬运。
• 平台迁移：从物理机/VMware 迁到云上（Azure SQL MI、AWS RDS for SQL Server）或从本地数据中心迁到新机房。核心矛盾是网络带宽、存储 IOPS 与安全合规。
• 架构重构：从单实例迁到 Always On 可用性组、从单体拆分为分库分表，或从 SQL Server 迁到 PostgreSQL/云原生数据库。核心矛盾是应用改造与数据一致性。
• 整合与拆分：多套小库合并到一套大实例以降低许可成本，或把超大库按业务域拆分以提升可维护性。核心矛盾是对象命名冲突、跨库查询与权限模型。

判断场景时，建议先回答三个问题：停机窗口有多长？应用能否改代码？回退容忍度是多少？这三个答案基本决定了后续路线。

二、核心挑战：大型库与小型库的本质差异

小型库迁移，备份还原即可；大型库迁移，挑战集中在五个维度：

• 数据量与传输时间：10 TB 数据库在 1 Gbps 链路上理论传输约 22 小时，实际受压缩、加密、磁盘读写影响往往翻倍。停机窗口内无法完成全量搬运，必须采用“全量 + 增量 + 切换”的组合策略。
• 停机窗口极短：核心系统可能只允许 30 分钟停机。这要求大部分工作在线完成，最后只做一次短暂的元数据切换与增量追平。
• 兼容性与行为差异：跨版本升级时，废弃特性（如旧版全文索引、兼容级别 100 以下的查询计划）、排序规则冲突、CLR 程序集、链接服务器等都可能引发问题。
• 性能回退风险：新版本优化器可能改变执行计划，原本正常的查询变慢。需要提前用 Query Store 与执行计划对比来识别。
• 回退与一致性：迁移失败时能否快速回退？切换瞬间如何保证源库与目标库数据一致、应用无脏读？这需要明确的切换点与回退预案。

三、关键成功要素

结合大量工程实践，成功迁移通常具备以下要素：

• 充分的评估与基线：迁移前采集源库的对象清单、数据量、索引碎片、等待类型、Top 慢查询，形成性能基线，作为迁移后对比依据。
• 可回退的切换设计：明确切换点、回退触发条件与回退操作步骤，并实际演练一次。
• 自动化与可重复：脚本化对象迁移、数据校验、性能对比，避免手工操作引入差异。
• 业务方全程参与：停机窗口、验证用例、验收标准必须由业务确认，而非 DBA 单方面决定。
• 分阶段验证：结构验证、数据验证、功能验证、性能验证、压力验证，逐层通过再切换。

四、整体方法论：五阶段迁移框架

下面这张图给出了一套可复用的迁移升级全景框架。它把迁移拆成评估、设计、准备、执行、验证五个阶段，并标出每个阶段的关键产出与回退路径。注意：这不是线性流程，评估与设计可能反复迭代，验证阶段发现问题也可能回到准备阶段。

五、一个可参考的迁移决策表

下表把常见场景与推荐路线对应起来，便于在评估阶段快速定位方向。表中参数为示例性建议，实际需结合带宽、停机窗口与团队能力调整。

六、落地建议：从全景到行动

全景概览的价值在于让团队在动手前对齐认知。建议在项目启动时完成三件事：第一，用评估脚本采集源库的对象、数据量、兼容性与性能基线，形成量化报告；第二，根据停机窗口与数据量估算迁移路线，明确全量与增量的分工；第三，设计切换点与回退条件，并至少演练一次。只有把“评估—设计—准备—执行—验证”串成闭环，并在每个阶段留下可检查的产出，大型数据库迁移升级才能从高风险的一次性动作，变成可控、可复现的工程过程。