表结构一旦上线，改动成本会随着数据量增长而快速上升。所以在设计阶段多花半天，往往能省下后期几周的迁移改造工作。
一、命名规范统一
- 表名用小写 + 下划线，用业务名词而非缩写
- 字段名表达含义，不用 a、flag1 这类命名
- 关联字段与被关联表的主键命名保持一致
- 避免使用数据库保留字
规范的直接收益是：写 SQL 时不用查字典，接手的人不用猜。
二、主键与关联
- 主键使用无业务含义的自增或雪花 ID，避免用业务编号
- 业务唯一性用唯一索引约束，而不是靠应用层判断
- 关联字段类型必须与主表主键一致，否则索引会失效
业务编号做主键的代价
业务编号可能被修改、可能重复使用、可能很长的字符串。一旦成为主键，所有关联表都要跟着改。
三、字段类型与长度
| 场景 | 建议 |
|---|---|
| 金额 | 定点小数类型，不使用浮点 |
| 时间 | 统一使用标准时间类型，不用字符串存时间 |
| 状态 | 用短整型或枚举，不用中文文本 |
| 文本 | 区分定长与变长，长文本单独考虑 |
四、索引：按查询来设计
- 先列出核心查询场景，再决定索引，不要"每个字段都加索引"
- 组合索引注意字段顺序，把区分度高的放前面
- 避免在索引列上做函数运算，会导致失效
- 定期检查未被使用的索引，及时清理
五、五个必要的公共字段
建议每张业务表都带上：创建时间、更新时间、创建人、更新人、逻辑删除标记。它们在排查问题、数据审计、误删恢复时都会派上用场。等到需要的时候才加，通常已经补不回历史数据了。
#数据库设计#表结构#索引策略#软件事业部
