SQL Server运维踩坑14年，实战指南专治数据库疑难

　　我原以为那个死锁是应用层的事，结果查完锁等待链发现是 tempdb 里一个没加 schema 的 INSERT SELECT 在凌晨三点把 version store 给撑爆了——去年二月份，就那会儿，上线前两小时，王磊蹲在工位底下拽测试机的充电线，够不着，线不够长。

　　你记得不？就是那个“订单状态异步更新后查不到”的偶现 bug。不是查不到，是查得到，但状态比事务提交晚三秒，三秒里前端已经刷出“处理中”，后台日志却还写着“待触发”。我们复现了十七次，十六次成功，一次失败——失败那次没记时间戳，只记得白板上数字擦了一半，剩个“7”，像条蚯蚓。

　　优胜劣汰？真不是喊口号。十四年，真刀真枪撞出来的：能活过三个大版本迭代的运维策略，八成靠的是被线上打脸打得最狠的那几个晚上。不是所有问题都进知识库，有些连提单都没走完就凉了——比如那个凌晨四点回滚脚本多删了两行注释，直接把 job 调度表主键给 DROP 了，李薇边敲 rollback 边把三台手机全摆在显示器右下角，微信、钉钉、飞书各占一台，全都亮着，谁也没看。

　　用例管理工具一直在转圈。不是卡，是转，绿色圆圈，每秒转一圈，转了三十八分钟，我盯着它想通了一件事：我们漏测的根本不是边界条件，是“非典型执行路径下的索引失效”。那个漏测的案例？SQL Server 2019 CU15 里，当数据库兼容级别设为140，且查询含 APPLY + 多层嵌套 CTE，而执行计划缓存被清空的瞬间，参数嗅探会选错基数估计模型——但只发生在首次编译后恰好第7次重用的时候。我们没覆盖这个路径。不是没设计，是回归轮次排得太密，冒烟跑完就直接压测，没人敢动那套老的 plan cache 清理脚本。

文章配图，仅供参考

　　这事儿站得住的地方就在这儿：没人教你怎么防第7次重用时的基数估计偏移，但连续两年以上没被这个bug打穿灰度的团队，要么删掉了那个 SQL，要么改了执行方式，要么干脆加了个 OPTION (RECOMPILE)——管用不管用先不说，至少它挺过了两次双十一大促。这不是经验，是淘汰。筛下来的全是活下来的姿势。

　　我翻过三年前的用例文档，自己写的，密密麻麻七十二页。最后一页空白，我补了行字：“本用例集未覆盖任何 runtime 环境波动引发的统计信息陈旧导致的计划退化。”——结果上周发现，压根没人看那第七十二页。连我自己，现在都懒得打开。键盘上有个键按下去不回弹，Ctrl 键，按三次才响应，搞得我切窗口总卡住，只能用 Alt+Tab 凑合。

　　跟开发争执那次，其实没吵赢。我说“这 SQL 要加 hint”，刘工说“hint 是遮羞布”，我甩出执行计划对比图，他反手就贴出 query store 里过去三个月的平均 CPU 耗时曲线——平得像尺子量过。我说“可偶现啊”，他说“偶现≠必现，必现≠致命，致命≠要你改”。后来还是运营同学凌晨两点发钉钉：“用户投诉订单查不到，已拉群。”我们才把那个 hint 加进去。加完跑了两天，又删了。因为发现真正的问题是 job 每小时强制更新统计信息时，把用户表的列级统计干掉了，而索引维护任务又把它漏过去了。不是 SQL 的事。是流程的裂缝。

　　所以说优胜劣汰，不是嘴上说的。是你哪天突然发现，自己写了十年的监控告警规则，只剩三条还在生效——剩下那些，要么被业务绕过去了，要么被 DBA 关掉了，要么，压根就没配过阈值。就像那个 tempdb 版本存储告警，最早我配的是“版本存储空间 > 2GB 就发邮件”，后来改成“连续5分钟 > 1.2GB”；再后来，换成“tempdb 文件增长速率 > 30MB/min & 持续超限6次”；上个月，它彻底停了——DBA 把自动增长关了，全部手工预分配。告警没用了。人还活着。系统更稳了。

　　我不信什么最佳实践。信什么？信张浩改完那个 backup job 后多加的一行 WAITFOR DELAY '00:00:02'——就因为某次 restore 时日志备份链断了一毫秒，他硬生生加了延时。这事没进文档，没人写进 SOP，只有他自己服务器上那份私藏的 PowerShell 脚本里留着注释：“防IO抖动，别问，问就是试出来的。”

　　所以现在我只干两件事：第一，把每次线上阻塞的 wait_type 抓下来，不分析，先存；第二，每季度翻一次没被触发过的告警配置，一条条删。删到心疼为止。剩下的，交给下一次凌晨三点的报警来筛选。

　　对了，你上次提的那个死锁截图，我存在桌面上，文件名是“deadlock_202402_记不清是哪个迭代了”，还没看。今天先把那个 tempdb 日志清理逻辑补全再说。

（编辑：站长网）

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