去年夏天，我帮一个做电商的朋友迁移数据库。他那台老服务器已经撑了三年，硬盘读写慢得像蜗牛爬，每次大促活动前都得提前关掉几个查询功能。他找到我，说新机器早就买好了，但数据库迁移这事儿拖了半年，总觉得麻烦。我理解这种心理——数据库不是普通文件，拷过去就能用，里面全是客户的订单、库存、会员积分，一个不小心丢几条记录，损失都是实实在的金钱。但说实话，SQL Server 迁移只要理清步骤，真的没想象中那么吓人。
迁移前最怕什么？怕的是直接上手干，连个备份都没留。很多人觉得把数据库文件复制到新机器，附加一下就能用，结果遇到版本不一致、账户权限丢失、或者系统表打不开，只能干瞪眼。我的习惯是，第一步先确认两个服务器的 SQL Server 版本。2022 版往 2019 版迁移时，有些新特性用不了，比如 JSON 函数或智能查询处理，可能导致应用直接报错。第二步是备份，全量备份是底线，最好再做个差异备份，万一迁移中出现问题，至少能回滚到上一个完整状态。朋友那台老机器跑着 2008 R2，新机器是 2019，版本相差好几代，直接附加数据库文件风险太大，我建议他用备份还原的方式，这是微软官方推荐的路径，稳定可靠。
备份这一步，很多人图省事，直接用 SQL Server Management Studio 的图形界面点几下就完事。但在生产环境里，我更喜欢写脚本。加上 COMPRESSION 参数，备份文件能小一半，传输起来快不少。尤其是数据库有几十个 GB 时，压缩的优势立竿见影。朋友那库有 80 GB，压缩后只有 38 GB，用 U 盘拷过去也就十来分钟。另外别忘了备份系统数据库，尤其是 master 和 msdb。如果新服务器要保留 SQL Agent 作业、维护计划或登录名，这些信息都藏在系统库里。不备份的话，迁移完成后会发现所有自定义的定时任务都没了，得一个个重建，那才叫崩溃。
把备份文件拷到新服务器后，还原操作也有讲究。很多人打开 SSMS，右键数据库选“还原”，一路点“确定”，结果碰到“数据库正在使用中”的错误提示。这是因为还原会独占数据库，如果还有其他连接在访问——比如某个应用池没断开，或者有后台作业在跑——就会卡住。正确做法是先在还原窗口的“选项”页里勾选“关闭现有连接”，或者用脚本加上 WITH REPLACE 参数。我习惯写脚本：这里的 MOVE 参数特别重要——老服务器的数据文件在 C 盘，新服务器可能想放到 D 盘，不指定路径的话，还原会按原路径创建，如果目录不存在，就会直接失败。
数据文件还原成功只是第一步，接下来要处理登录名和用户映射。这是最容易出问题的地方。老服务器上，应用通过一个叫 “webappuser” 的登录名连接数据库，这个登录名在 master 库里的 SID（安全标识符）是固定的。但迁移到新服务器后，如果只是还原数据库，新系统里没有这个登录名，或者有同名但 SID 不同，应用连接时会报“用户登录失败”。解决方法是提前在老服务器上导出所有登录名的脚本，包括密码哈希。可以使用 存储过程，或者在 SSMS 里生成登录名脚本，勾选“脚本整个登录名”。把生成的脚本在新服务器上执行，创建登录名，再还原数据库并映射用户。我见过有人忘了这一步，迁移后折腾了两天才发现只是缺少一个登录名。
还有一个容易被忽略的点：链接服务器和扩展存储过程。有些系统会通过链接服务器访问其他数据库，比如从 SQL Server 查询 Oracle 数据。链接服务器的配置存放在 master 库里，迁移后需要重新创建。扩展存储过程更麻烦，例如 这类系统命令默认是禁用的，得手动开启。还有第三方组件，如数据库邮件功能、全文索引配置等，都要在新服务器上重新设置。最好的办法是迁移前把老服务器的配置做个清单，一条条核对。我习惯用 PowerShell 脚本把所有配置导出成文本，迁移完成后逐项比对，比在 SSMS 里点来点去快多了。
性能调优这块，很多人以为数据迁移完就结束了，其实恰恰相反。新服务器硬件不同，CPU 核心数、内存大小、磁盘类型都变了，老服务器上的索引碎片统计信息可能不再适用。比如老机器是机械硬盘，你建了很多非聚集索引来减少随机 I/O，但新机器用的是 NVMe 固态硬盘，随机读速度翻了几倍，原来的索引反而可能成为写操作的负担。迁移完成后，第一件事是更新所有表的统计信息：然后检查索引碎片率，对碎片超过 30% 的索引做重建。另外别忘了调整 SQL Server 的内存配置——默认情况下，SQL Server 会占用几乎所有可用内存，但如果新机器上还跑着其他应用（如 IIS 或 Redis），需要给它们留出空间。使用 设置上限，一般建议保留约 20% 的内存给操作系统。
测试环节不能省，但很多人嫌麻烦直接跳过。我朋友当时急着上线，我说至少得跑一轮关键业务流程。他的电商系统核心功能是下单、支付、库存扣减。我写了个简单的测试脚本，模拟 100 个并发用户同时下单，观察新服务器的响应时间。结果发现有个存储过程比老服务器还慢——原因是新机器的兼容级别是 150，而老版本 2008 R2 的兼容级别是 100。兼容级别变化后，优化器会选择不同的执行计划，导致性能回退。解决办法是先把数据库兼容级别设为 100，等应用稳定后再逐步升级到 150，并配合查询存储功能监控性能变化。这一步花了我们整整一天，但避免了上线后用户投诉页面打不开的尴尬。
说个很多人不知道的细节：迁移完成后，记得清理老服务器上的数据库文件。不是出于安全考虑，而是为了省钱。朋友的案例里，老服务器是租的云主机，按磁盘容量付费。数据库虽然迁走了，但数据文件和日志文件仍占着几十 GB 空间，白白扣了两个月费用。另外，新服务器上建议开启备份压缩和定期完整性检查。SQL Server 自带的 命令能检测物理和逻辑错误，建议每周跑一次，发现坏页能及时修复。迁移不是终点，而是运维的新起点。数据库就像水管，换了个新水龙头，但水质好不好、水压稳不稳，还得持续盯着。
