SQL Server数据库设计避坑12实战要点

　　2025年9月17号下午三点十七分，我在客户现场盯着SSMS里那个刚建完的“用户行为宽表”——主键设的是（tenant_id, event_time, device_id）三个字段组合，bigint+datetime2+varchar(64)，看着挺稳。
　　结果上线第六次压测，凌晨一点四十二分，监控钉钉弹窗炸了：订单插入延迟飙到八秒，事务堆积两百多个，日志里反复刷着“死锁图检测到循环依赖”。

　　我原以为是索引没建对，删了重建，加了include字段，把device_id换成hash值——没用。再看执行计划，发现每次INSERT INTO都顺带触发了个隐藏的UPDATE：原来开发在视图定义里嵌了JOIN三张表，而那张宽表恰好被这个视图引用，SQL Server自动把INSERT转化成MERGE逻辑……可谁也没在DDL里写MERGE啊？
　　老张蹲在旁边啃冷包子，说：“你猜怎么着？上个月他们用SSDT生成过一次发布脚本，里头有段‘ALTER VIEW xxx AS SELECT …’硬生生把宽表当基表塞进FROM子句——脚本跑了，人没review。”

　　茶水间咖啡机漏液第三天，维修单还挂在IT工单系统里没关。

文章配图，仅供参考

　　我们回滚到上线前的版本，手动DROP掉那个视图，重跑部署脚本，死锁立刻没了。但第八次压测到七千QPS时，又卡住——这次是tempdb日志文件撑爆，因为宽表上有个计算列用的是GETDATE()，而那个列被建了非聚集索引……SQL Server每插一行都得算一次当前时间，还锁住sys.syscommittab去取事务时间戳。
　　王工敲键盘敲出残影，头都没抬：“早说别在索引列里放函数。”
　　我说：“没放函数，放的是GETDATE()，它不算函数——官方文档里写着‘确定性函数列表不包含GETDATE’。”
　　他愣了三秒，吐出一句：“哦，所以它算‘运行期常量’？那它更该进黑名单。”

　　其实真坑不在这儿。真正让我后背发凉的是——这张宽表从设计评审开始就没被任何人拿去跑过SET STATISTICS XML ON，连我自己都跳过了。
　　就因为上回在另一个项目用同样结构扛住了双十一，所以这次直接Ctrl+C/V建表语句，连GO都懒得敲两次。
　　我也不知道为啥当时觉得“这结构优胜劣汰过了”，反正就是信了。

　　服务器机柜最下层左数第二格，贴着张泛黄便签，字迹是前年写的“勿动UPS开关”，上面落了灰。
　　上周五行政说保洁阿姨误拔过一次网线，导致测试环境同步中断了二十来分钟——这事儿跟宽表死锁毫无关系，但那天所有人第一反应都是查网线。

　　现在问题是：同一个库、同一张宽表、同一个INSERT语句，在DEV环境跑得飞起，在UAT却稳定死锁——连锁等待资源名都不一样：DEV里等的是KEY: 8:72057594038321152:37，UAT里等的是PAGE: 8:1:124387。
　　统计信息更新了，填充因子调了，隔离级别从READ COMMITTED改成SNAPSHOT——全试过。
　　可只要打开那个视图（哪怕不SELECT，只ALTER VIEW），问题就回来。
　　它就像埋在代码里的活物，你不碰它，它装死；你一动它，它就咬你脚踝。

　　有谁碰到过这个吗

（编辑：航空爱好网）

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