那天下班前，我正收拾东西准备溜，同事小张慌慌张张跑过来：“哥，咱那台老旧的SQL Server要迁移，客户只给了5分钟停机窗口，你能搞定不？”我心想这不是要我命吗，但嘴上还是说“没问题”。其实谁都知道，数据库迁移看似简单，踩过的坑比天上的星星还多。今天我把这几年死磕SQL Server迁移的经验掰开来讲给你听，争取让你也能在五分钟内实现数据无缝衔接。
很多人一提到迁移，第一反应就是备份还原、附加分离，觉得复制粘贴就完事了。但现实往往很打脸——版本不兼容、排序规则不匹配、用户权限丢失、作业脚本跑不起来，哪个坑都能让你加班到天亮。就拿版本兼容性来说，SQL Server 2008直接还原到2019，八成会报错。你得先看清楚源库和目标库之间的版本跨度，超过两个大版本时，最好走中间版本过渡，或者用脚本导出再导入。别嫌麻烦，这一步省了，后面省的是你的头发。
再说个常见的坑——排序规则。我见过一个案例，生产库是 ChinesePRCCIAS，目标库默认是 SQLLatin1GeneralCP1CIAS，结果查询时中文乱码，索引完全失效。这个坑太隐蔽，备份还原时根本不会报错，但运行起来全是问题。解决办法也简单：迁移前在建库脚本里明确指定排序规则，或者在还原后用 ALTER DATABASE 改过来。别偷懒，这一步花不了两分钟，却能救你一命。
用户权限和登录名迁移也是个老大难。备份还原只搬数据，不搬登录名。你兴冲冲把库还原到新服务器，一开应用就出现一堆登录失败。因为源库里的用户和目标服务器上的登录名是两码事，SID 对不上。解决方案是使用 sphelprevlogin 这个系统存储过程，把登录名和 SID 一起导出，再在目标服务器上重建。还有更省事的办法，直接用 SSMS 的“生成脚本”功能，把登录名、用户、权限全部勾上，生成完整的迁移脚本，跑一遍基本搞定。
作业（Job）和 SSIS 包的迁移很容易被忽略。这些自动化任务在旧服务器上跑得好好的，换了环境全挂。原因很直接——作业里引用了旧服务器名、旧路径、旧账户。我的做法是先把所有作业脚本化，导出成 .sql 文件，然后在目标服务器上全局替换服务器名和路径。至于 SSIS 包，更麻烦一点，因为它可能依赖环境变量和配置表。最好在迁移前把所有依赖项列个清单，逐项核对。别指望一次跑通，至少预留一次调试时间。
性能调优这块，很多人觉得迁移完就算完事了。其实这才是开始。同样的数据、同样的查询，在新服务器上可能慢得像蜗牛。原因可能是统计信息没更新、索引碎片化严重，或者新硬件下执行计划变了。迁移完成后的第一件事，就是更新所有表的统计信息，重建或重组索引。我一般跑一个脚本，遍历所有用户表，自动完成这些操作。花不了五分钟，却能让数据库跑得跟之前一样快，甚至更快。
还有个细节——日志文件。很多人迁移时只盯着数据文件，日志文件随便放。结果还原后发现日志疯长，磁盘空间秒爆。正确的做法是在还原时指定日志文件的初始大小和自动增长参数，保持和源库一致。如果不确定，可以先用 RESTORE FILELISTONLY 命令查看源库的文件信息，再手动指定路径和大小。这一步看起来啰嗦，但能避免后续大量磁盘报警。
说说验证。迁移完别急着收工，至少跑一遍关键业务查询，检查数据条数是否一致、主键和外键是否完整、触发器和存储过程是否正常。我习惯写一个简单的校验脚本，对比源库和目标库的表记录数、校验和（CHECKSUM），确保数据零丢失。如果条件允许，再做一次用户验收测试，让业务部门跑几个典型场景。只有他们说“没问题”，迁移才算真正完成。
回到开头小张的问题。五分钟停机窗口确实紧张，但不是不可能。前提是提前做好功课：把版本兼容性、排序规则、登录名、作业、性能调优这些问题都预先解决，把脚本和步骤写清楚，现场只剩执行和验证。说白了，所谓“五分钟搞定”，背后是至少一天的准备工作。别怕麻烦，准备工作做得越细，现场就越稳。数据库迁移从来不拼手速，拼的是细心和对坑的预判能力。下次再有人问你“五分钟能搞定吗”，你就把这篇文章甩给他，然后说：“只要按这个来，五分钟真的够用。”
