ClawHub

数据库模式设计

Data & APIs

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

Install

openclaw skills install qqyougit-database-schema-designer

数据库模式设计 🗄️

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