C盘红了，最让人头疼的事之一就是SQL Server数据库占着地方不走。系统盘那点空间，被数据库文件一点点蚕食，日志文件更是膨胀得离谱。你说删吧，不敢；你说不管吧，服务器天天报警。这时候唯一的出路就是给数据库搬家，把数据文件挪到别的盘去。这事听起来简单，实际操作起来，坑比想象中多得多。
先搞清楚一件事，SQL Server的“数据库”不是单个文件，它由主数据文件（.mdf）、日志文件（.ldf），可能还有次要数据文件（.ndf）组成。很多人迁移的时候只挪了.mdf，结果日志文件还在C盘躺着，等于白干。更麻烦的是，还有tempdb、系统数据库这些隐藏角色，它们的迁移逻辑跟用户数据库完全是两码事。所以动手之前，先打开SSMS看一眼数据库属性，把所有文件的路径都记下来，心里有数再操作。
最简单的迁移方式，是用SSMS的图形界面。右键数据库，任务，分离，然后把文件物理移动到新盘，再附加回来。这个方法直观，适合新手，但有个致命前提：数据库必须处于离线状态。如果你的系统是7×24小时在跑，分离就意味着业务中断，那得挑凌晨低峰期干。而且分离附加有个恶心的地方，一旦中途断电或者文件损坏，数据库可能直接起不来，恢复起来比迁移本身还费劲。
那有没有不停机就能迁的办法？有，用ALTER DATABASE命令配合MODIFY FILE指定新路径。这招的核心是让SQL Server自己把文件搬过去，全程数据库保持在线，业务不受影响。具体操作分两步：先把逻辑文件名改成新路径，然后执行ALTER DATABASE来物理移动。整个过程SQL Server会自己处理文件句柄，但有个隐藏要求——磁盘必须有余量做中间拷贝，因为它是先复制再删除原文件，不是直接剪切。
还有一群人会想到备份恢复的方式，把数据库备份出来，还原到新路径。这方法最保险，因为备份文件是完整的快照，还原的时候可以指定到任意盘符。但代价是时间窗口长，大数据库备份加还原可能耗好几个小时，期间的增量数据全丢了。除非你能接受业务有短暂延迟，或者配合日志备份做时间点还原，否则生产环境慎用。
迁移过程中最容易翻车的是权限问题。文件挪到新盘后，SQL Server服务账户必须对新目录有完全控制权限，否则启动时直接报错，数据库显示“可疑”状态。很多人栽在这，数据库文件明明在，就是挂不上。解决办法是给MSSQLSERVER服务账号授予NTFS权限，别偷懒用Everyone，安全性和稳定性都差。另外，新盘的磁盘格式得是NTFS，FAT32不支持大文件，也别用压缩卷，性能会打折扣。
还有个常被忽略的细节：tempdb。这玩意儿是临时数据库，每次SQL Server重启都会重建，但它默认在C盘，而且频繁读写，对系统盘压力极大。如果你要彻底解决C盘空间问题，tempdb必须一并迁走。用SQL查询tempdb的逻辑文件名，然后同样用ALTER DATABASE改路径，但注意tempdb的迁移重启后立即生效，不用做物理文件移动，因为系统会重新创建。不过多个tempdb文件的话，最好分布在不同的物理盘上，能分散I/O压力。
日志文件迁移是另一大难题。事务日志增长快，挪走之后还得防它再爆。迁移日志文件的方法跟数据文件一样，但有个特殊之处：日志文件没法缩小到初始大小以下，就算你收缩了，它内部还是保留着虚拟日志文件。所以迁移前建议先做一次完整备份，再收缩日志，把文件压到最小再移。不然你挪过去一个80GB的日志，新盘空间瞬间又紧张了。
实际操作的时候，我建议先拿测试库练手。别一上来就对生产库动刀，先在虚拟机或者测试环境把整个流程走一遍，记录每步的耗时和报错信息。尤其是那种几十GB的大库，迁移时间可能远超预期，你要估算好窗口期。另外，迁移前务必做一次完整备份，并且验证备份文件能正常还原，这是你的救命稻草。宁可多花半小时备份，也别在出问题的时候抓瞎。
迁移完成之后，别急着庆祝，验证工作才是重头戏。先用DBCC CHECKDB检查数据库完整性，确认没有逻辑损坏。然后跑几个常用查询，看看性能有没有变化。如果新盘是机械硬盘，而原来在SSD上，那查询延迟可能会明显上升，这时候要考虑是否把高频访问的表挪到文件组上，或者干脆给新盘做条带化。还有监控磁盘空间，看日志文件是否又涨回来了，如果涨得飞快，说明有长事务没提交，得排查代码。
说点实在的，数据库迁移不是一锤子买卖，它应该是你存储规划的一部分。C盘只放操作系统和程序，数据库文件、日志、备份全部扔到独立的数据盘上。给C盘预留20%以上的空闲空间，给数据盘做好RAID，定期监控各盘的使用率。如果你的服务器已经跑了好几年，平时疏于管理，那这次迁移正好是个契机，把数据库文件重新梳理一遍，该归档的归档，该清理的清理。毕竟，数据库搬家只是手段，让系统稳定高效地跑下去才是目的。
