数据库设计规范

问题从哪来

多人协作或项目拉长周期后，表结构往往会出现命名风格混用、VARCHAR 不给长度、金额用浮点、外键没索引、审计字段一套 created_at 另一套 gmt_create 等问题。这类细节不会立刻让服务挂掉，但会让 SQL 难读、迁移风险变高，线上排查也更费时间。

技能在约束什么

本规范把关系型库（以 MySQL 常见实践为主）的设计拆成可执行的约定，适合在 建表评审 或 DDL 合并前 对照使用。

• 命名：表用小写复数 + 下划线；关联表 {表A}_{表B} 按字母序；列用 user_id、is_active、created_at；索引用 idx_ / uk_ 前缀。
• 必备字段：id、created_at、updated_at，审计需要时补 created_by / updated_by；同一项目只选一种审计命名风格，禁止混用。
• 类型：主键与计数用 BIGINT；金额 DECIMAL(18,2)；时间 DATETIME；布尔用 TINYINT + 注释，避免滥用 ENUM。
• 索引：为 WHERE、JOIN、ORDER BY、GROUP BY 与唯一业务键建索引；组合索引遵循等值在前、区分度高的列在前、最左前缀；避免低基数单列索引与大字段索引。
• 关系与软删：1:N、N:M、树形与版本化有对应实现方式；软删用 is_deleted 或 deleted_at，唯一约束需把删除标记纳入设计。
• 迁移：DDL 进版本控制，变更尽量前向兼容，破坏性修改分步发布；生产环境慎删表、删列、改名。

文末 严禁清单 汇总了主键缺失、SELECT *、外键无索引、NULL 滥用、单表列数过多等常见反模式。

适用边界

规范偏 工程约定与评审清单，不替代具体业务的容量规划、分库分表方案或 ORM 映射细节。外键可选物理约束或逻辑外键，但无论哪种，外键列都应建索引。反范式冗余字段必须写清原因，避免为省一次 JOIN 而长期背负数据不一致。