干我们这行的，谁还没被 SQL 数据库日志爆满折磨过？凌晨三点，手机突然狂震，监控报警说磁盘空间只剩几百兆，你一边在心里骂娘，一边爬起来检查，发现日志文件已经膨胀到几十 GB，甚至上百 GB。这种绝望感，懂的人都懂。别问我为什么知道——上周我就刚经历过一次，某客户的 ERP 系统直接卡死，销售单子打不出来，老板急得团团转。说实话，日志爆满这事儿，80 % 的情况是我们自己没管好，剩下的 20 % 是设计时埋的雷。今天我把压箱底的三招掏出来，全是实操干货，不废话，直接上。
第一招最简单，叫“截断日志法”。很多人一听“截断”就慌，觉得要丢数据，其实不是。日志文件记录的是数据库的变更历史，比如你更新了一条记录，日志里会写“谁、什么时候、把什么字段从 A 改成了 B”。这些历史记录不是永远都有用，一旦你做了完整备份，之前的日志就可以安全清理。操作也很简单：在 SQL Server Management Studio 里，对着你的数据库右键，“属性”→“选项”，把恢复模式从“完整”改成“简单”。然后右键数据库，“任务”→“收缩”→“文件”，文件类型选“日志”，直接点确定。几秒钟功夫，几十 GB 的日志文件就缩成几十 MB。不过要提醒你，这招治标不治本，改完恢复模式后数据库就失去了时间点恢复能力，万一出事只能恢复到上次完整备份的时间点。所以这招适合数据不那么敏感、或者能接受丢失最近几小时数据的场景。
第二招叫“日志备份 + 收缩”，适合需要保留完整恢复能力的场景。操作分三步走：先做一次日志备份，让日志文件里的“非活动部分”标记为可重用。然后执行 DBCC SHRINKFILE 命令，把日志文件物理缩小。记得设置定期日志备份计划，比如每 15 分钟备份一次，这样日志文件就不会无限制膨胀。我见过最夸张的案例，某公司日志文件长到 300 GB，磁盘只剩 2 GB 空间。他们 IT 用这招，先备份日志，再收缩，文件直接降到 2 GB。但问题来了：为什么日志会从 2 GB 又慢慢涨回 300 GB？因为根因没找到。日志爆满的罪魁祸首往往是三点：事务长时间未提交、索引维护操作、或者数据库设计时没考虑归档策略。比如某段代码里开启了事务却忘记提交，或者半夜跑了一个重建索引脚本，这些都会导致日志疯狂增长。所以第二招的核心不是“怎么清”，而是“怎么防止它再满”。
第三招是“根源治理法”，这才是真正的一劳永逸。检查你的数据库恢复模式：如果是“完整”模式，确保日志备份频率足够高。我建议关键业务系统每 5 分钟备份一次日志，普通系统每 30 分钟一次。排查是否有长事务：用 DBCC OPENTRAN 命令，看看有没有事务开了几小时还没提交。我遇到过最离谱的一次，某开发在测试环境开了个事务，忘了关，结果把生产环境的日志撑爆了。调整数据库的自动增长设置：别让日志文件每次增长 10 %，而是设置成固定大小增长，比如每次增加 512 MB，避免频繁的自动增长导致性能抖动。另外，给日志文件预留足够的初始空间。比如你算出业务高峰期一天产生 5 GB 日志，就直接把日志文件预分配 10 GB，省得它天天自动膨胀。
但光有这三招还不够，你得学会“预防”。我的习惯是：所有生产数据库监控磁盘空间使用率，低于 20 % 就报警；同时监控日志文件大小，如果 24 小时内增长超过 10 %，立刻查根因。另外，每周做一次日志文件使用率分析，看看哪些数据库的日志利用率低于 50 %，说明日志备份做得到位；哪些高于 80 %，就赶紧去查原因。这些监控脚本网上大把，花半小时配置好，能省下无数个被电话吵醒的夜晚。
说个真实案例吧。去年我接了个金融客户的活儿，他们的核心交易系统日志爆满，每次都要手动清理，运维快疯了。我一看，发现他们的恢复模式是“完整”，但日志备份频率只有“每天一次”。更离谱的是，完整备份每周才做一次。这意味着日志文件里存着整整一周的变更记录，能不大吗？我帮他们改成每 10 分钟备份一次日志，完整备份改成每天一次，同时把日志文件初始大小从 1 GB 改成 10 GB。一个月后回访，日志文件稳定在 8 GB 左右，再没爆过。客户运维说：“早知道这么简单，我何必熬那半年夜。”
说句掏心窝的话：数据库日志管理，核心就四个字——“控制增长”。你控制不住增长，再牛逼的清理手段都是白搭。就像你家下水道，光靠疏浚不行，还得管住上面别乱扔东西。日志备份频率、恢复模式选择、事务提交习惯、初始空间规划，这四点抓牢了，日志爆满基本跟你绝缘。要是你已经被日志问题折磨得欲仙欲死，赶紧试试这三招。别等了，再等下去，老板的夺命连环 Call 又要来了。
