SQL Server数据库设计避坑实战指南

　　去年十月份那项目，数据库设计直接给我整破防了。产品经理拍着胸脯说"就这么点东西"，结果需求文档改了十八版，表结构跟着改了二十一次——最后上线前三天，测试机屏幕上还飘着"对象名无效"的报错。我蹲在工位底下啃凉了的外卖，手机屏幕上是地铁上掏出来复现的SQL：原以为把订单状态拆成枚举值能省空间，结果业务方突然要支持"已取消可恢复"这种中间态，直接把tinyint干成了varchar(20)，索引效率直接腰斩。

　　优胜劣汰这事儿在数据库设计里太真实了。我原以为给用户表加个"最后登录IP"字段没啥大不了，结果运维半夜打电话说主从复制延迟——后来一查，原来是某个小版本SQL Server对varbinary(16)的存储优化有问题，同样的数据量，用varchar(15)存IP字符串反而更快。这事儿我敢打包票，因为当时桌上排着三台测试机，每台跑不同存储方案，监控大屏上三条曲线跟股票K线似的，varchar那条直接甩开另外两条两个身位。

　　最坑的是外键约束。开发说"必须加，保证数据一致性"，测试说"加了之后并发插入直接超时"，产品说"用户注册流程不能卡顿"。最后妥协方案是在应用层做校验，结果上线第二周就出事故——某个接口漏了校验逻辑，数据库里攒了三百多条"订单表有记录但用户表没对应ID"的脏数据。那天凌晨三点，我蹲在机房地上改存储过程，运维小哥在旁边嗦泡面，汤汁溅到键盘上，我俩谁都没敢擦——怕手抖把正在跑的UPDATE语句给断了。

　　索引设计更是玄学。我原以为给高频查询字段加复合索引准没错，结果某个查询走了索引反而比全表扫描慢三倍。后来用执行计划一看，好家伙，SQL Server优化器选了最左前缀匹配，但实际查询条件里最左边的字段选择性太低，导致索引扫描范围比全表扫描还大。这事儿我说不准是优化器的问题还是设计的问题，反正最后是删了那个索引，改用覆盖索引才解决——但覆盖索引又占空间，存储成本又上去了，产品经理看到账单时那表情，跟吃了苍蝇似的。

　　还有数据类型选择。有个字段存金额，我用了decimal(18,2)，结果财务系统对接时说精度不够——他们要存到小数点后四位。改吧，表结构得变，历史数据得迁移；不改吧，财务系统死活不接。最后折中方案是在应用层乘100存成整数，数据库里用bigint，显示的时候再除回去。这事儿现在想起来还后怕，要是当初直接用了float，现在财务对账不得炸锅？

文章配图，仅供参考

　　现在回头看，那些没踩过的坑才叫坑。比如有个项目用NOLOCK提示提升并发，结果读到脏数据导致用户看到重复订单；还有个项目把日志表和业务表放同一个文件组，结果大事务阻塞时连日志都写不进去，直接宕机。这些坑现在说起来轻描淡写，当时可都是通宵改代码的噩梦。

　　所以说数据库设计哪有什么完美方案？都是权衡出来的。优胜劣汰的意思不是一开始就选最好的，而是边踩坑边调整，把不合适的方案淘汰掉。就像我工位上那盆绿萝，刚搬来时枝繁叶茂，现在只剩两根光杆——但至少还活着，比那些直接养死的强多了。

　　最近在研究SQL Server 2022的新特性，听说智能查询处理能自动优化执行计划，不知道能不能少踩点索引设计的坑。不过话说回来，就算有新功能，该踩的坑还是一个都少不了——毕竟业务需求永远比技术更新快，产品经理的脑洞永远比数据库的扩展性强。

（编辑：站长网）

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