数据库模式设计 🗄️#

When to Run#

• 新项目需要设计数据库架构
• 审查/优化现有数据库设计
• 需要从业务需求推导数据模型
• 需要索引策略建议
• 需要数据库迁移方案

Workflow#

Step 1: 需求分析#

• 收集业务实体和关系（用户、订单、产品...）
• 确定数据量级（当前/预估增长）
• 确定读写比例（读多写少/写多读少）
• 确定一致性要求（强一致/最终一致）
• 确定数据库选型：关系型/文档型/键值型/时序型

Step 2: 概念建模（ER图）#

• 识别实体、属性、关系
• 确定关系类型：1:1 / 1:N / M:N
• 绘制ER图（Mermaid语法）
• 标注业务规则和约束

Step 3: 逻辑设计#

• 确定规范化级别（3NF为默认，必要时反范式）
• 设计表结构：字段名/类型/约束/默认值
• 设计主键策略（自增/UUID/雪花算法）
• 设计外键关系和级联规则
• 设计索引策略

Step 4: 物理设计#

• 选择数据类型和精度
• 设计分区/分表策略（大数据量）
• 设计索引（B-Tree/Hash/复合索引/覆盖索引）
• 估算存储空间

Step 5: DDL生成#

• 输出CREATE TABLE语句
• 包含注释、约束、索引
• 附带迁移脚本模板

Step 6: 设计评审#

• 检查规范化合规
• 检查索引覆盖查询模式
• 检查扩展性（水平/垂直拆分预案）
• 检查安全性（敏感字段加密/权限）

输出模板#

text

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🗄️ 数据库设计 | {项目名} | {数据库类型}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## 1. ER图
{mermaid ER diagram}

## 2. 表结构
### {表名}
| 字段 | 类型 | 约束 | 说明 |
|------|------|------|------|
| id | BIGINT | PK, AUTO_INCREMENT | 主键 |
| ... | ... | ... | ... |

### 索引设计
| 索引名 | 字段 | 类型 | 说明 |
|--------|------|------|------|
| idx_xxx | field1, field2 | BTREE | 用途说明 |

## 3. DDL语句
{SQL CREATE TABLE}

## 4. 设计说明
- 规范化：{说明}
- 分表策略：{说明}
- 扩展预案：{说明}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

数据库选型速查#

场景推荐原因传统业务系统MySQL/PostgreSQL成熟稳定，事务支持复杂查询/分析PostgreSQL高级查询/JSON支持文档/灵活结构MongoDBSchema-free高频缓存/会话Redis内存级速度时序数据InfluxDB/TDengine时序优化全文搜索Elasticsearch倒排索引

索引策略速查#

场景建议等值查询单列B-Tree索引范围查询范围字段放复合索引最后排序排序字段加入复合索引覆盖查询复合索引包含SELECT字段高区分度优先区分度高的字段放索引前面避免不在低区分度字段建单列索引

高级设计模式#

多租户架构#

模式适用优缺点共享库共享表SaaS小客户成本最低，隔离最弱，需tenant_id字段共享库独立表SaaS中客户隔离适中，DDL管理复杂独立库大客户要求隔离最强，成本最高

向量数据库集成（AI/RAG场景）#

• PostgreSQL + pgvector：适合小规模（<100万向量），事务一致
• Milvus/Qdrant：大规模向量检索，独立部署
• 混合查询：先向量检索Top-K → 回查关系库补全业务字段

安全迁移策略#

• 蓝绿迁移：新表并行写入 → 数据同步验证 → 切换读路径 → 旧表下线
• 大表DDL：使用pt-online-schema-change或gh-ost避免锁表
• 回滚预案：每次迁移必须有逆向脚本，先测试环境验证

信用/交易系统特殊设计#

• 幂等性：所有写操作必须带幂等键（idempotency_key），防重复提交
• 乐观锁：余额变更使用 version 字段，UPDATE WHERE version = ?
• 审计日志：关键操作记录 change_log 表（who/when/before/after）
• 软删除：金融数据禁止物理删除，使用 deleted_at + reason

约束#

• 所有表必须有主键
• 敏感数据（密码/手机号）必须标注加密要求
• 大表（>1000万行）必须提前规划分区/分表
• 外键慎用（性能影响），优先应用层保证一致性
• DDL必须包含字段注释
• 金融/信用系统必须设计幂等性和审计日志

Output Language#

中文输出，DDL和字段名用英文

Anti-rationalization#

借口正确做法"需求已经很清楚了，直接建表吧"必须完成Step 1需求分析全部5项确认（实体关系、数据量级、读写比例、一致性要求、数据库选型），缺一不可"先用VARCHAR存所有字符串字段，以后再说"必须为每个字段选择精确的数据类型和长度，VARCHAR需注明最大长度合理性依据"外键太影响性能了，不加了"必须在设计说明中显式说明外键策略：是使用物理外键还是应用层保证，并给出理由"索引加多了影响写入，少建几个"必须基于实际查询模式设计索引，每个索引都要标注其服务的查询场景，不能凭感觉跳过"这个项目数据量不大，不需要考虑分区"必须评估未来12个月数据增长预估，超过1000万行的表必须提前规划分区/分表策略"DDL写个大概，注释后面补"DDL必须包含所有字段注释、约束说明，禁止使用TODO占位"直接用UUID做主键，简单省事"必须说明主键策略选择理由（自增/UUID/雪花算法），并分析对索引和写入性能的影响