数据库模式设计

新项目建表拍脑袋，上线后慢查询满天飞？从需求到ER图到DDL到迁移策略，设计生产级数据库架构。覆盖规范化建模、索引策略、多租户设计、分库分表、向量数据库集成。支持MySQL/PostgreSQL/MongoDB/Redis/Milvus。 触发词：数据库设计、表结构设计、schema设计、ER图、建表、数据库建模、索引优化、数据库架构、数据模型、范式、反范式、分库分表、数据库迁移、DDL、数据库审查、多租户设计、向量数据库、RAG存储、信用评估系统、交易系统数据库 排除：SQL查询优化（用python-data-analysis）、ORM代码生成、数据库运维（用docker-deploy-assistant）

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支持
文档/灵活结构	MongoDB	Schema-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/雪花算法），并分析对索引和写入性能的影响