一、写在前面：为什么规范比技巧更重要  

在团队规模膨胀、需求迭代飞快的今天，“写得快”往往战胜“写得对”。一条缺少索引的查询在测试环境悄无声息，一旦上线便拖垮整库；一个随意命名的字段在三个月后让新同事摸不着头脑。规范不是束缚，而是让所有人用同一套语言沟通、用同一把尺子衡量。本文尝试将近二十年的社区经验与踩坑教训，浓缩成一份可落地、可演进、可审计的数据库设计规范，供架构师、开发者、DBA、测试共同参照。

二、规范全景：一条需求如何变成表  

当产品经理说“用户需要收藏文章”时，这条需求在数据库层面的旅程可以拆成七步：  
1. 业务语境澄清（谁收藏、收藏什么、何时收藏）  
2. 概念模型抽象（实体、关系、属性）  
3. 逻辑模型落地（表、字段、约束）  
4. 物理模型优化（索引、分区、分片）  
5. 命名与注释（语义化、多语言团队友好）  
6. 审计与版本（谁改的、何时改、为何改）  
7. 回滚与灰度（上线后如何安全后退）  
下文所有条文都围绕这七步展开，既有原则也有示例，方便直接引用。

三、概念建模：先讲清故事再画图  

原则 1：用“一句话”定义实体  
   收藏关系可描述为“用户对文章的喜爱行为快照”。这句话同时隐含了主语（用户）、宾语（文章）、动作（喜爱）、时间（快照）。  
原则 2：拒绝万能表  
   把“用户资料、订单、发票”塞进同一张宽表的诱惑巨大，却会在未来带来稀疏列、更新热点、锁竞争三重灾难。  
原则 3：关系优先于属性  
   先画出“用户-收藏-文章”三条线，再决定线上挂什么属性。关系错了，属性再多也是错的。

四、逻辑建模：范式与反范式的拉锯  

规范 4：三范式是起点，不是终点  
   1NF 保证列原子性；2NF 消灭部分依赖；3NF 消除传递依赖。  
   在报表系统里，适当反范式（冗余汇总字段、宽表）可减少 join，但需配套冗余更新策略。  
规范 5：主键必须稳定  
   雪花算法、UUID、自增主键各有优劣，关键是“永不回卷、永不重复、绝不暴露业务含义”。  
规范 6：枚举值必须落表  
   用字典表而不是字符串硬编码，避免国际化或业务变更时的批量改代码。

五、物理建模：性能与容量的平衡术  

规范 7：索引不是越多越好  
   每多一个索引，写操作就多一次 B+ 树维护。建议“查询驱动”而非“直觉驱动”。  
   识别慢 SQL 的三板斧：最左前缀、回表次数、过滤因子。  
规范 8：分区先垂直再水平  
   垂直分区按列热度拆分，水平分区按时间或地域拆分。  
   分区键必须出现在所有查询的 where 子句中，否则退化为全表扫描。  
规范 9：冷热分层  
   热数据放 SSD，温数据放 SATA，冷数据下沉对象存储，生命周期策略由业务标签驱动。

六、命名与注释：写给三个月后的自己  

规范 10：统一大小写与分隔符  
   全小写加下划线，避免驼峰与帕斯卡混用。  
规范 11：表名即故事  
   user_favorite_article 比 fav_tbl 更易读；带业务前缀防止跨库重名。  
规范 12：字段顺序暗示逻辑  
   主键、外键、业务字段、审计字段、软删除标记，自上而下依次排布。  
规范 13：注释必须双语  
   英文术语保证一致性，中文说明帮助新人快速上手。  
   更新字段时同步更新注释，CI 中增加“注释缺失”门禁。

七、约束与默认值：把错误挡在数据库门口  

规范 14：NOT NULL 先行  
   允许 NULL 的列必须在文档里写清“为何可为空”。  
规范 15：默认值需显式  
   时间戳默认 now()、金额默认 0、状态默认 draft，防止业务代码遗漏。  
规范 16：唯一约束即业务断言  
   用户邮箱唯一、订单号唯一、优惠券码唯一，违背唯一约束等同于违背业务规则。  
规范 17：外键不是装饰品  
   外键带来级联更新/删除，需评估性能；若禁用外键，应用层必须实现一致性检查。

八、审计与版本：让每一次变更可追溯  

规范 18：迁移脚本即文档  
   每个 PR 必须包含正向迁移（up）和回滚脚本（down），脚本命名包含日期与工单号。  
规范 19：影子库演练  
   在影子库跑迁移脚本，验证执行时间与锁表范围，再上线生产。  
规范 20：字段灰度  
   新增字段默认 NULL 或默认值，双写阶段后逐步切换读路径，最后删除旧字段。  
规范 21：版本号语义化  
   数据库 schema 版本跟随应用版本，主版本号仅在破坏式变更时递增。

九、回滚与灰度：让错误有后悔药  

规范 22：蓝绿部署  
   蓝库跑旧版本，绿库跑新版本，流量切换在网关层完成，数据库零停机。  
规范 23：滚动回滚  
   先回滚应用，再回滚数据库，避免“代码旧、数据新”的死锁。  
规范 24：数据补偿  
   对不可逆操作（如 delete）保留软删除或 archive 表，回滚时只需 update 标志位。

十、测试策略：把规范变成自动门禁  

规范 25：单元测试覆盖迁移脚本  
   每段迁移脚本必须附带测试用例，验证字段、索引、默认值、约束是否生效。  
规范 26：契约测试  
   应用与数据库之间通过 JSON Schema 或 protobuf 描述接口，变更即触发测试。  
规范 27：混沌工程  
   每周随机杀库连接、打满磁盘、制造网络抖动，验证规范下的弹性。

十一、安全底线：最小权限与审计日志  

规范 28：账号三权分立  
   应用账号、只读账号、DDL 账号，分别授予最小权限。  
规范 29：审计日志留存  
   所有 DDL、敏感 DML 写入独立审计库，留存周期符合合规要求。  
规范 30：脱敏策略  
   非生产环境使用脱敏数据，防止备份泄露。

十二、性能基线：让规范可度量  

规范 31：慢查询阈值  
   测试环境 100 ms，预发 200 ms，生产 500 ms，逐级收紧。  
规范 32：索引覆盖率  
   慢查询中 90% 以上应命中索引，否则视为规范失效。  
规范 33：容量预警  
   磁盘 70%、内存 80%、连接数 90% 触发告警，提前扩容。

十三、文档与文化：让规范长在心里  

规范 34：Design Review 模板  
   每张表必须有“业务背景、读写比例、索引方案、预计容量、回滚策略”五段描述。  
规范 35：On-Call 手册  
   值班人员按手册排查“锁等待、慢日志、主从延迟”，避免拍脑袋。  
规范 36：新人训练营  
   两周内完成“设计一张表、写一段迁移脚本、跑一次回滚”三个任务，规范即上手。

十四、未来展望：从规范到自治  

1. 智能索引  
   通过机器学习分析慢日志，自动生成索引建议。  
2. Policy as Code  
   把命名、约束、权限写成声明式文件，CI/CD 自动校验。  
3. 数据网格  
   把数据库下沉为基础设施，规范由平台统一托管，开发者只关注业务语义。

十五、结语  

好的数据库设计规范，不是贴在墙上的 A4 纸，  
而是刻在每一次 CRUD、每一次迁移、每一次回滚里的肌肉记忆。  
把本文 36 条规范拆成 check-list，  
在下一个需求评审、下一次上线窗口、下一场故障复盘里逐一打勾，  
你会发现：规范不是枷锁，而是让团队跑得更快、更远、更稳的隐形翅膀。