数据库模式设计

SKILL.md

---
name: database-schema-designer
version: 1.4.0
description: |
  新项目建表拍脑袋，上线后慢查询满天飞？从需求到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: 设计评审
- 检查规范化合规
- 检查索引覆盖查询模式
- 检查扩展性（水平/垂直拆分预案）
- 检查安全性（敏感字段加密/权限）

## 输出模板

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

## 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/雪花算法），并分析对索引和写入性能的影响 |