站长必修：SQL Server运维避坑指南（12个真实故障复盘）

　　一个月前那台DL380的SQL Server集群，半夜三点报警炸得我差点把手机扔进冷却池。温升曲线直接顶穿阈值，内存占用率卡在99.7%死活降不下来——这场景我熟，八成又是tempdb堵了。结果爬进机柜一看，好家伙，C盘空间还剩12MB，tempdb日志文件把系统盘撑得跟怀胎十月的母猪似的。我原以为只是简单的空间释放，结果用DBCC SHRINKFILE卡了二十分钟没反应，最后硬是重启实例才苟住，修完我自己都没底。

　　这事儿让我想起上个月看的《站长必修：SQL Server运维避坑指南》，里面第十二个案例专门讲tempdb膨胀。那哥们儿更绝，日志文件直接把D盘啃穿，导致整个存储池挂掉。书里给的解法是改自动增长策略+定期收缩，我试了确实管用——但有个细节没人提：收缩前必须先查sys.dm_os_waiting_tasks，要是碰到PAGEIOLATCH_SH等待类型，这时候收缩就是往火坑里跳。这个我敢打包票，上周刚在客户现场踩过这坑。

　　车间那台风扇一直在响，旁边老张叼着烟抖腿："你说这帮写书的，怎么就不提硬件层的事儿？"他这话让我想起上周那台R740，SQL Server突然卡成PPT，排查半天发现是NVMe盘温控策略太激进，热保护触发后直接降频到500MB/s。我原以为改下BIOS设置就行，结果得刷固件——这个型号我只在别人那儿见过，刷完心跳得比第一次约会还快。

文章配图，仅供参考

　　中午盒饭里有块姜，我挑出来扔进垃圾桶时突然想起书里第七个案例：索引碎片导致查询超时。那哥们儿重建索引后问题解决，但没提碎片阈值到底设多少合适。我试过5%、10%、30%，最后发现得结合OLTP/OLAP场景——比如某电商的订单库，白天OLTP交易高峰期碎片率到15%才重建，晚上OLAP分析时5%就重建，这样既能保证性能又不浪费资源。不过这个我说不准，要看运气，有次碰到个奇葩存储，重建索引反而让I/O延迟翻倍。

　　手机在铁台上震了一下，是客户发来的截图：SQL Server错误日志里全是"A time-out occurred while waiting for buffer latch type 3"。这症状书里没提，但我知道是缓冲池竞争——要么是并发连接太多，要么是内存配置不合理。我让他先查sys.dm_os_buffer_descriptors，结果发现80%的页都是同一个大表，赶紧建议他分区表+调整内存分配。修完他问我："这要是再犯怎么办？"我盯着手套上一块硬掉的胶，没敢接话——有些问题，真不是靠调参能解决的。

　　书里最让我服气的，是优胜劣汰那部分。比如第五个案例讲死锁，那哥们儿没像某些二愣子一样直接开TRACE FLAG 1222，而是先用Extended Events抓死锁图，再用sp_whoisactive分析阻塞链，最后发现是两个存储过程互相持有对方需要的资源。这种逐步排查的思路，比某些"一键解决所有死锁"的脚本靠谱多了——我见过太多人，死锁一出现就狂改隔离级别，结果把事务一致性搞崩了。

　　谁把扳手掉地上了一声闷响，老张抬头："你刚才说优胜劣汰？"我点头："对，就像书里那个案例，运维没搞清楚业务特性就盲目加资源，结果钱花了问题没解决。"他吐了个烟圈："我倒是觉得，有些'劣'是逼出来的——比如去年那台老SQL Server，内存才64GB，业务却要跑10万QPS，我们硬是靠优化查询+缓存策略扛了半年，直到换新硬件。"

　　其实我也没拆到底。比如书里第二个案例讲CPU 100%，那哥们儿排查半天发现是统计信息过期导致查询计划走偏。但有些CPU高，可能是存储层的问题——比如我之前遇到过的，SQL Server等不到I/O完成，线程就卡在WAIT_ON_LOCK_RETURN，CPU占用看着高，其实是在空转。这种情况，改统计信息没用，得查存储延迟或者换更快的盘。

　　现在再看那本避坑指南，最实用的还是那些"反常识"结论。比如谁说SQL Server一定要用RAID 10？我们给某物流公司做的集群，用RAID 5+缓存盘，性能比RAID 10还好——当然，这得看 workload 类型。又比如谁说索引越多越好？我见过一个库，索引数量是表数量的3倍，结果DML操作慢得像蜗牛，删掉一半无用索引后，性能直接翻倍。

　　手套上的胶硬得能敲核桃，我摘下来扔进垃圾桶。下午还要去客户现场，那台SQL Server的等待类型又变了——这次是RESOURCE_SEMAPHORE，估计是内存压力。我摸了摸口袋里的U盘，里面存着那本避坑指南的电子版——有些坑，还是得边踩边学。

（编辑：应用网_常德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!