站长必修：SQL Server运维12大坑及避坑指南

　　我原以为2026年3月那场主从切换能撑过凌晨两点——结果凌晨一点五十七分，监控钉钉弹窗跳成一片血红，DBA老张一边抠键盘缝隙里的咖啡渣一边吼“日志没截断”，我抓起桌上那盒凉透的麻辣香锅扒拉两口，勺子柄还沾着芝麻酱就抄起鼠标切到AG Dashboard。界面卡在“状态：正在解析”十八秒。我数了——就十八秒。不是二十，不是十七。十八。

　　坑一：自动增长设10%，但文件实际已占满LUN，底层存储告警灯亮了半小时没人看，直到SQL Server报错代码9002把所有应用进程挂成僵尸。那天机房空调坏了，嗡嗡声比平时高半个八度，运维小李蹲在机柜前用听诊器贴着磁盘背板听异响，结果听见的是隔壁楼施工打桩——我们仨对着震颤的U盘支架笑出声，笑完继续盯IO等待队列。这个我敢打包票：9002从来不是SQL的问题，是人忘了看存储告警邮件被规则归档进“低优先级”文件夹。你翻一下去年Q4的邮件日志，第三封标题带“[CRITICAL] LUN usage >95%”的，发件时间是周四下午四点零三分，附件里有截图，但没有标红框——人只扫标题，不点开。

　　坑二：备份策略写着“全备+日志每十五分钟”，可备份作业调度器配的是“每十五分钟执行一次”，而实际脚本里没加SET LOCK_TIMEOUT 5000，某次日志备份碰上一个没提交的事务，卡住三小时十七分钟。我翻作业历史时发现中间穿插七个“执行成功（0）”记录——全是虚假心跳。你猜怎么做到的？脚本末尾加了个GO后面紧跟PRINT 'OK'再EXIT，SQL Agent看到返回码0就记成成功。这事儿我没深究谁写的，但那天凌晨三点四十，实习生小陈端着保温杯站我工位边问“老师，备份失败是不是因为事务没结束”，我说“对”，她又问“那为啥显示成功”，我就把保温杯接过来喝了一口——水温刚好，不烫嘴也不凉，就是有点甜，可能是她泡枸杞放多了。我没答她第二问。

　　坑三：Always On侦听器DNS缓存没清，客户侧连不上新主节点，排查花了四个小时。中间市场部王总监来敲我隔板三次，第三次敲完掏出手机调出微信聊天记录，指着一句“刚才技术说已恢复”给我看。他指甲剪得很短，但右手中指有个旧疤，像被螺丝刀划的。我没接他手机，顺手把他放在桌沿的折叠伞推回他那边——伞尖还滴着水，地上摊着一小片暗痕，像地图上的未命名湖泊。

　　坑四：索引维护计划里用了UPDATE STATISTICS WITH FULLSCAN，但表有八亿行，统计信息更新跑了一整夜，第二天早上十点才发现。我查作业日志时顺手点开服务器资源监视器，看见内存使用率87.3%，但SQL Server自己报告内存只用了42GB——差的那部分被WMI Provider Host吃掉，而它正好在跑一个PowerShell脚本，循环读取Win32_PerfFormattedData_SQLServer_SQLServerBufferManager。这事儿我说不准，没查源码，但那个PowerShell脚本的名字叫“SQL_Health_Check_v2.ps1”，创建时间是2025年12月19日，修改时间是2026年3月1日——改的人删了sleep -seconds 30那行，就删了这行。

　　坑五：TempDB八个数据文件，但初始大小全设成1GB，自动增长步长却设成512MB——结果每次查询跑HASH JOIN都得等文件扩容，扩容又撞上磁盘队列深度飙升。有天我把这配置抄给外包兄弟，他说“哎哟这个我熟”，转身就去改生产库，三分钟后他QQ头像变成灰色，微信回我：“我刚把tempdb文件删了两个。”我回他：“别动，先连上SSMS，看下sys.master_files里file_id最小的是几。”他过了半分钟发来截图，file_id=1和2是tempdev和templog，剩下从3开始。我说：“那你删的应该是3和4。”他回了个哭脸。我没再说话。窗外雨停了，但排水管还在滴，嗒、嗒、嗒，频率很稳，像计时器。

文章配图，仅供参考

　　优胜劣汰？没错。踩过这十二个坑里七个以上的，现在基本都在做架构或者已经转岗。活下来的不是技术多好，是摔得够狠、记性够差、下次还敢用同样的脚法踢同一块石头。我桌上还有半块没拆封的固态硬盘，标签纸撕了一半，写着“SQL2022测试用-勿动”，字迹是我自己写的，但我不记得啥时候写的了。要不……今晚回去试试用PowerShell批量删掉所有SQL Server服务里的Start Mode=Manual项？试完再决定要不要留着这半块硬盘。

（编辑：站长网）

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