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

文章配图，仅供参考

　　饮水机在旁边咕嘟响，我盯着执行计划里那串全表扫描的箭头，突然想起三年前在东莞工厂看到的场景——流水线上的工人在给手机壳贴膜，膜歪了0.1毫米就全废。数据库设计也这德行，索引没建对，查询效率能差两个数量级。那天运维小哥蹲在机房门口抽烟，说“哥你这表设计得，连SQL Server自己都看不懂”。

　　第一个坑是外键约束。我原以为设个外键能保证数据一致性，结果测试环境跑着跑着就报死锁——订单表关联用户表，用户表又关联地址表，三个表的外键像俄罗斯套娃似的嵌套。后来发现是某个查询语句同时更新了用户表和地址表，SQL Server的锁升级机制直接把整个库锁了。现在想想，互联网项目哪有那么多强一致性需求？最终解决方案是砍掉所有外键，改用触发器做异步校验。

　　风扇把快递单吹到地上时，我正盯着监控大屏上的慢查询列表。有个统计报表的SQL写了200行，全是子查询嵌套子查询，执行计划里全是Nested Loop。我让后端改写成JOIN，结果他说“JOIN会影响分页性能”——分页用LIMIT 10 OFFSET 10000这种写法，JOIN确实会扫全表，但问题是你TM为什么要分页到第1000页？后来直接砍了分页功能，改用无限滚动加载，慢查询立马消失。

　　第二个坑是字符集。有个字段存用户备注，设计时随手选了nvarchar(200)，结果某个用户写了500个汉字，直接截断。更坑的是，前端传的是UTF-8编码，SQL Server默认用Latin1解析，存进去全是问号。测试妹子抱着笔记本过来问“哥你看这数据怎么乱码了”，我盯着屏幕上的“?????”看了五分钟，突然想起去年在杭州参加技术峰会，有个阿里P9讲过“字符集是数据库设计里最容易被忽视的定时炸弹”。

　　鼠标垫卷边了，我把它扯平又卷起来。第三个坑是分区表。业务系统要按年份分区，我照着文档写了CREATE PARTITION FUNCTION，结果发现分区键必须是主键的一部分。而主键是自增ID，跟年份没关系。最后只能把分区键改成日期字段，但历史数据已经存了，迁移时用了三天三夜，运维小哥差点辞职——他说“哥你这分区方案，比给大象做阑尾炎手术还难”。

　　仓库卷帘门哗啦一声响，送货的来了。我想起上个月跟工厂老板吵架的事——他要给每个产品加10个自定义属性，我说“这得改表结构，增加20个字段”，他拍桌子说“你们程序员就是死板，用JSON存不就行了？”。后来真用了JSON，结果财务系统要统计“红色产品”的数量，写了个LIKE '%"color":"red"%'的查询，把索引全废了。现在那表还躺在数据库里，像个定时炸弹。

　　第四个坑是默认值。有个状态字段设计时设了默认值0，结果业务逻辑里0代表“未处理”，1代表“处理中”，2代表“已完成”。但有个接口没传这个字段，SQL Server自动插了0，导致系统误以为所有新订单都已处理。测试妹子发现时，已经有2000个订单被错误标记，客服电话被打爆。后来我在设计文档里加了一行红字：“所有状态字段禁止设默认值，必须显式赋值”。

　　打包台上横着的那卷胶带，让我想起第五个坑——事务隔离级别。有个批量导入功能，用了BEGIN TRANSACTION，结果并发导入时大量事务等待，数据库连接池被打满。我原以为把隔离级别从SERIALIZABLE改成READ COMMITTED就能解决，结果发现是某个存储过程里用了NOLOCK提示，导致脏读。现在那存储过程还躺在代码库里，注释写着“慎用，可能读到脏数据”，但没人敢改。

　　第六个坑是索引维护。我设了个定期重建索引的Job，结果发现某个表每天新增100万数据，重建索引要锁表20分钟，业务系统直接停摆。后来改成在线重建，但SQL Server 2016的在线重建有bug，偶尔会丢索引。运维小哥说“哥你这Job比定时炸弹还危险”，现在那Job被禁用了，改用每周日凌晨3点手动维护——虽然影响小，但总有人忘记执行。

　　有人在旁边点外卖，我闻到红烧肉的味道。第七个坑是数据类型选择。有个金额字段用了float，结果计算时出现精度丢失，0.1+0.2不等于0.3。财务妹子拿着计算器过来对账，发现差了3分钱，差点把审计引来。后来改成decimal(18,2)，但历史数据已经存了，迁移时用了个笨办法：先导出成CSV，再用Python脚本转换，最后导入新表——整个过程花了两天，运维小哥说“哥你这数据类型选得，比选股票还难”。

　　第八个坑是视图设计。我建了个复杂视图，关联了10个表，结果某个查询用了这个视图，执行计划里全是Hash Match。优化器建议我建索引，我建了，结果发现视图里的子查询又用了另一个视图，形成嵌套视图链。现在那视图还躺在数据库里，注释写着“慎用，性能极差”，但新来的开发总爱用它——直到被慢查询报警炸醒。

　　我承认，这12个避坑点里，有些是SQL Server特有的（比如分区表必须包含主键），有些是通用的（比如字符集问题）。但优胜劣汰的逻辑是通的——设计时偷的懒，上线后都要还。现在我看新项目的数据库设计文档，第一件事就是查主键、索引、字符集，这三个地方但凡有一个不对劲，直接打回重写。毕竟，谁也不想在凌晨3点被运维电话炸醒，说“哥，数据库又锁表了”。

　　至于那12个避坑点的完整列表？等我把这杯咖啡喝完再写——现在先得去处理个紧急工单，财务系统又报“金额计算错误”了，八成又是float类型惹的祸。

（编辑：航空爱好网）

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