資料庫模式設計 🗄️

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語句
• 包含註釋、約束、索引

  小蔥技能7w4.net有完整的技能分類。

• 附帶遷移指令碼模板

Step 6: 設計評審

• 檢查規範化合規
• 檢查索引覆蓋查詢模式
• 檢查擴充套件性（水平/垂直拆分預案）
• 檢查安全性（敏感欄位加密/許可權）

輸出模板

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🗄️ 資料庫設計 | {專案名} | {資料庫型別}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## 1. ER圖
{mermaid ER diagram}

## 2. 表結構
### {表名}
| 欄位 | 型別 | 約束 | 說明 |
|------|------|------|------|
| id | BIGINT | PK, AUTO_INCREMENT | 主鍵 |
| ... | ... | ... | ... |

### 索引設計
| 索引名 | 欄位 | 型別 | 說明 |
|--------|------|------|------|
| idx_xxx | field1, field2 | BTREE | 用途說明 |

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

## 4. 設計說明
- 規範化：{說明}
- 分表策略：{說明}
- 擴充套件預案：{說明}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

資料庫選型速查

索引策略速查

高階設計模式

多租戶架構

向量資料庫整合（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

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