干数据库这行的，谁没碰上过文件迁移这档子事儿呢？尤其是 SQL Server，动不动就几百 GB 的数据文件，迁移起来真能把人折腾得够呛。我入行那会儿，第一次接手迁移任务，心里直打鼓，生怕把公司的核心业务给搞崩了。后来才发现，这事儿其实没那么玄乎，关键是要摸清门道。说白了，迁移就像搬家，规划得好，一天就能搞定；要是瞎折腾，可能得花三天收拾烂摊子。
先说最基础的，你得弄清楚自己手里面对的是哪种迁移场景。是同一台服务器换个盘符，还是跨服务器搬家？是数据库还在跑着就得动，还是可以停机操作？不同场景，方案完全不一样。比如同一台服务器换盘符，用 改文件路径就行，几步操作的事儿。但要是跨服务器搬，就得考虑网络带宽、目标磁盘的读写速度，甚至还要检查防火墙有没有阻断端口。我见过最离谱的，有人直接拿 U 盘拷贝几百 GB 的文件，结果 U 盘读写速度慢得像蜗牛，迁移足足拖了两天。
迁移前，准备工作必须扎实。第一件事，备份再备份。别嫌啰嗦，真要是一步操作失误，数据全毁了，老板可不让你安稳。备份完了，还得检查目标服务器的磁盘空间、SQL Server 版本、补丁是否一致。我吃过一次亏，把 2012 版的数据搬到 2016 版上，结果兼容性问题冒出来，索引重建失败，查了好久才发现是版本差异。另外，别忘了看看目标服务器上有没有同名的数据库，否则一恢复就会炸。这些琐碎细节，往往是迁移翻车的导火索。
正式动手，主流玩法有两种：脱机迁移和联机迁移。脱机迁移最稳妥，先把数据库设为离线，拷贝文件，再附加到目标服务器。步骤简单，适合小库或能接受短时间停机的业务。比如凌晨两三点搞，用户都睡了，随便操作。联机迁移稍复杂，需要用到日志备份和事务复制，保证数据不丢。我有个朋友，公司要求零停机，他折腾了三四个小时，用镜像复制搞定，结果晚上睡觉都梦见数据在飞。说实话，没那个金刚钻，别揽瓷器活，新手还是老老实实停机搞。
文件路径的坑也得注意。SQL Server 默认装在 C 盘，但数据文件最好别放系统盘，万一系统重装，数据就没了。迁移时，很多人图省事，直接把文件拖到 D 盘，结果忘了改路径，启动数据库时报错“找不到文件”，慌得一批。其实用 改一下路径就行，但得先查清楚逻辑文件名。还有一种情况，文件路径里带空格或中文，SQL Server 会识别混乱，最好全部使用英文路径。这些细节，写脚本时多检查几遍，能省不少麻烦。
大文件迁移，速度是硬伤。几百 GB 的文件，网络传输慢得要命，尤其是跨机房甚至跨城市。我建议先用压缩工具打包再传，能省一半时间。但别用默认的 Zip，效率低，建议 7‑Zip 或 RAR，压缩级别调低点，省时间。还有个小技巧，先迁移主文件（.mdf），再迁移日志文件（.ldf）。日志文件通常较小，迁移顺序搞反了，可能导致数据库启动不了。要是网络实在不行，直接拿硬盘拷贝，物理运输比在线传输靠谱得多。
迁移完，别急着庆祝，验证才是关键。第一，检查数据库状态，确保是 “正常” 模式。第二，跑几个核心查询，看看数据是否一致。第三，别光看数据，还要测性能。我见过一次迁移，文件放到了慢速磁盘上，查询响应时间从 0.5 秒飙到 10 秒，用户直接骂娘。用 检查完整性，再做一次压力测试，看看读写速度。要是发现问题，赶紧调磁盘配置或索引。别等用户投诉了再补救，那时你的 KPI 已经悬了。
日志文件的处理也不能忽视。很多人只盯着数据文件，日志文件随便丢，结果事务日志暴涨，磁盘空间报警。迁移时，最好把日志文件单独放在一个盘，容量预估大一点。我习惯把日志文件改成简单恢复模式，迁移完再切回完整恢复模式，省得日志膨胀。但有个前提，迁移过程不能有数据修改，否则日志丢了就恢复不了。要是业务还在跑，就别动日志模式，老老实实做日志备份。
说说心态。数据库迁移这事儿，经验比理论更值钱。我见过老手十分钟搞定，也见过菜鸟折腾一宿。关键是多练、多复盘。每次迁移完，记下步骤、踩过的坑，下次就能避开。实在没把握，找台虚拟机模拟一下，跑通流程再动手。别怕失败，怕的是失败后不长记性。数据库这行，细节决定成败，你多花十分钟检查，可能就省了别人一天的时间。
