凌晨三点，手机警报声把我从梦里拽出来。监控平台显示，某台SQL Server的磁盘可用空间归零了。说实话，看到这个数字的时候，我后背瞬间就出汗了——不是冷，是吓的。数据库磁盘满了，后果可不是闹着玩的：事务日志写不进去，用户连接全部卡死，最要命的是，如果这时候数据库崩溃，连恢复的空间都没有。我赶紧爬起来开电脑，一边远程连服务器，一边在脑子里过了一遍处理流程。今天把这事写出来，就是想让同样干这行的兄弟们少走点弯路。
先说最紧急的一步：立刻确认到底是什么文件把磁盘塞满了。别急着删东西，先跑一条SQL语句，看看数据库文件和日志文件各占了多少空间。用sys.masterfiles这个系统视图，可以查到每个数据库文件的实际大小和已用空间。我那次查完发现，罪魁祸首是日志文件，已经膨胀到50多G了，而数据文件才用了不到10G。这就好办了，日志文件是可以收缩的。但这里有个坑：如果你用的是简单恢复模式，日志文件理论上不会无限膨胀，可一旦出现过大的事务或者长时间未提交的事务，日志照样能撑爆磁盘。
如果查下来发现是日志文件的问题，第二招就是执行CHECKPOINT，把内存中的脏页写回磁盘，然后备份日志或者直接截断日志。具体操作很简单，先切换成简单恢复模式，再执行DBCC SHRINKFILE，把日志文件收缩到合理大小。但这里要提醒一句：简单恢复模式下，你无法做时间点恢复，如果业务对数据安全性要求极高，这个操作要格外谨慎。我当时就是先和业务方确认了情况，才动手的。毕竟，数据安全永远是第一位的，哪怕慢一点，也不能为了图快把数据弄丢了。
再说说另一种常见情况：如果数据文件本身就把磁盘占满了，那就得考虑清理历史数据了。别一上来就删表，那是自杀式操作。正确的做法是，先看看数据库里有没有大表，用sys.dmdbpartitionstats这个DMV，可以快速统计出每个表占用的空间。找到那些占用空间大、而且确实是历史数据的表，和业务方确认清楚，再批量归档到别的存储上。比如把两年前的数据导出成文件，或者迁移到归档库。删除数据的时候，最好分批删，每次提交一批，别一次性delete几百万行，那会让事务日志膨胀，搞不好又是一场灾难。
还有一个很多人容易忽略的点：临时数据库tempdb也可能把磁盘塞满。tempdb是SQL Server的临时工作区，排序、哈希联接、临时表全用它。如果你的系统跑着重大的报表查询或者批量操作，tempdb瞬间能涨到几十G。怎么判断？还是用sys.masterfiles，看看tempdb的文件大小就知道了。如果发现tempdb膨胀了，先别急着重启服务，那样虽然能强制清空tempdb，但正在运行的查询会全部失败，影响面更大。正确的做法是找到产生大量tempdb使用的会话，用sys.dmexecrequests配合sys.dmexecsqltext，定位到具体的SQL语句，看看是不是有笛卡尔积、排序过度或者索引缺失的问题。
处理完紧急情况，磁盘空间暂时恢复了，但这才只是开始。真正的功夫在平时，我见过太多人处理完告警就撒手不管，结果过两周又炸一次。你得把这次事故当成一个体检报告，好好查一查：数据库的自动增长设置是否合理？是不是每次增长1%这种不靠谱的配置？建议改成固定大小增长，比如每次增长512MB或者1GB，避免频繁的自动增长导致文件碎片化。还有，维护计划里有没有定期收缩数据库？如果有，赶紧去掉，收缩数据库会造成严重的索引碎片，性能下降可不是闹着玩的。
另外，磁盘监控这块也得升级。别等可用空间归零了才收到告警，那太晚了。建议把告警阈值设置在磁盘总空间的15%到20%，给留出充足的缓冲时间。同时，把数据库的文件增长监控也加上，一旦发现某个文件在短时间内快速增长，马上能定位到具体是哪个库、哪个操作引起的。我记得有一次，就是通过这个监控，发现某个开发人员跑了一个没有WHERE条件的UPDATE，差点把整个库给搞崩了。及时发现，及时止损，这才是运维该干的事。
说到这儿，我想起一个特别容易翻车的细节：很多人处理完磁盘空间后，会顺手把数据库的恢复模式从简单改回完整。但改回去之前，一定要做一次完整备份，否则日志链断了，后续的日志备份全都白搭。而且，改回完整模式后，别忘了定期备份日志，不然日志文件又会慢慢膨胀，又是同样的坑。这些操作看着琐碎，但每一条都是前人用血泪教训换来的。
总结一句重话：SQL Server磁盘空间归零，不是偶然事件，它一定是某个环节出了问题。可能是索引碎片太多，可能是日志没定期备份，可能是某个查询写得糟糕，也可能是监控配置不合理。处理完紧急情况后，花点时间把根因挖出来，比啥都强。我这几年处理过几十次类似告警，每次都能找出点平时忽略的隐患。数据库这个活儿，就是个细水长流的功夫，平时多用心，关键时刻才能不慌。这次的指南就到这儿。
