哥们儿，你是不是也遇到过这种破事儿？数据库跑得正欢，突然蹦出来个错误：“tempdb的日志已满”，瞬间整个系统卡得像老牛拉破车。搞IT的都知道，tempdb这玩意儿就是SQL Server里的“临时工”，啥脏活累活都往它那儿堆，排序、分组、临时表、游标，全指望它。可这“临时工”一旦日志满了，就跟人便秘似的，堵得慌。别慌，这事儿我碰上过不少次，今天咱们就掰扯掰扯，怎么把这“日志已满”的坑填平。
先说最直接的解决办法：扩容。你打开SQL Server Management Studio，右键点tempdb，选属性，找到“文件”选项卡，把日志文件的初始大小和自动增长调大。比如说，原来日志初始200 MB，自动增长10%，你直接改成500 MB或1 GB，自动增长设成20%或固定增长500 MB。这招儿跟给手机加内存卡一样，空间大了自然不卡。但注意，别贪心设太大，万一磁盘满了，连重启都麻烦。我见过一哥们儿，一激动把日志设成100 GB，结果磁盘爆了，整个库都瘫了。所以扩容前，先看看磁盘剩余空间，心里有个数。
可光扩容，治标不治本。tempdb日志满，多半是事务没提交，或者跑了个超长查询，导致日志文件疯狂膨胀。这时候得查查是啥在作怪。用个简单命令：，它能列出当前未提交的事务。比如，你跑 ，系统会告诉你哪个会话ID在占着茅坑不拉屎。然后你 ，把它干掉，日志立马就释放了。我干过一回，一个死锁的事务卡了三天，日志撑到30 GB，KILL 完瞬间掉到200 MB，那感觉比夏天喝冰可乐还爽。但小心，KILL 事务可能丢数据，最好先跟业务方确认，别莽撞。
还有一种情况，是tempdb的恢复模式是“完整”的，这玩意儿像记流水账的会计，啥操作都记录，日志自然疯长。解决办法是改成“简单”模式。右键 tempdb，属性，找到“选项”，把恢复模式从“完整”改成“简单”。然后执行 ，系统会主动截断日志，释放空间。我有个朋友，公司数据库的 tempdb 日志从未超过2 GB，改成简单模式后，稳定在500 MB 左右，省心多了。但注意，这招儿只适合 tempdb，别乱改用户数据库，否则数据会丢失。
说到这儿，你可能会想：能不能定期清理 tempdb 日志？当然可以，但得讲究方法。别直接删日志文件，那是自掘坟墓。正确做法是收缩日志：。比如 ，把日志缩到 1 GB。但收缩前，要保证日志里没有活跃事务，否则缩不动。我试过几次，收缩后系统性能明显提升，尤其在高并发场景下。不过别频繁收缩，它本身也耗资源，一周一次就够了。
除了这些应急招儿，还得从根本上防。tempdb 日志满，很多时候是 SQL 语句写得烂。比如，你写个 ，结果没清理临时表，或者用了游标循环，每循环一次就生成一堆日志。优化一下：少用 ，多指定字段；临时表用完就 ；能用表变量就别用临时表，因为表变量日志开销小。我见过一个电商系统，订单查询用了游标，每次跑 100 万行，tempdb 日志直接飙到 50 GB。后来改成集合操作，日志降到 2 GB，速度还快了 10 倍。
还有个冷门但管用的招儿：给 tempdb 加文件。SQL Server 允许 tempdb 有多个数据文件和日志文件。你可以再建一个日志文件，比如 ，放在不同磁盘上，能分散 I/O 压力，降低日志满的风险。我有个同事把 tempdb 日志拆成两个文件，一个放 SSD，一个放 HDD，结果高并发时日志增长慢了一半。不过注意，文件数别超过 CPU 核心数，否则效果反而差。
说个我踩过的坑。一次生产环境，tempdb 日志爆满，我傻乎乎地重启了 SQL Server 服务。结果 tempdb 被重建，日志清了，但所有未提交事务都丢了，业务方差点把我骂死。正确做法是：先 ，在线扩容，再查活跃事务。如果实在不行，就切到单用户模式，，强制回滚事务，然后改大小。这招儿狠，但管用，适合紧急情况。
所以，tempdb 日志满不可怕，关键是要明白：它只是个临时工，别让它当甩手掌柜。平时多监控，给日志设个上限，比如最大 20 GB，避免疯长。写 SQL 时多留个心眼，别搞大事务。万一真满了，别慌，先扩容，再查事务，优化代码。记住，数据库这东西，跟养孩子似的，定期体检比啥都强。
