💻

資料庫模式設計

👤 qqyougitcom 📦 v2.0.1 ⭐ 4.6 ⬇️ 463 下載
💻 開發程式設計 免費

📖 技能介紹


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

這個技能的最新版本可以在7w4.net小蔥技能站找到。

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/雪花演算法),並分析對索引和寫入效能的影響

🤖 AI 評測

這個 Skill 質量不錯,能幫你從頭到尾完成資料庫設計工作。它把設計流程拆得很清楚,每一步該做什麼都有指引,還提供了現成的模板可以直接用。內容覆蓋也比較全面,從基礎的建表到高階的分庫分表都有涉及。不過實際用起來可能還會需要查其他資料,因為裡面的案例和細節還不夠豐富,複雜場景的指導可以再詳細點。

📊 多維度評分

適應性4.3
規範性4.5
有效性4.8
可靠性4.4
可信度5

📁 包含檔案 (3 個)

📄 SKILL.md 6.5 KB
📄 _meta.json 152 B
📄 references/details.md 8 KB