MySQL 數據庫設計實戰：引擎選型、定長/動態表、冗余字段、分表分庫策略

面向高併發讀多寫少的互聯網業務，MySQL 設計核心原則：性能優於範式，冗余優於 JOIN，分片優於單表大數據。

1. 引擎選型

互聯網核心業務**默認 InnoDB**；MyISAM 僅用於非關鍵、可重建的緩存/統計表。

2. 行格式：定長 vs 動態

• 定長表：所有列定長（CHAR/INT/DATETIME），無 VARCHAR/BLOB/TEXT。優點：偏移量定位快、易恢復；缺點：佔空間大。
• 動態表：含變長列。優點：節省空間；缺點：更新可能導致行遷移、碎片化。
• 建議：核心高頻查詢表盡量定長（如用 CHAR(32) 存 MD5、TINYINT 存枚舉），輔助表用動態。

3. 容量預估

單行大小 = Σ 列定長 + 變長列平均長 + 開銷(約 20-30 字節)
表總大小 = 單行大小 × 預估行數 × 1.3 (冗余因子)

超過 2000 萬行/單表 5GB 考慮分表。

4. 冗余字段減少 JOIN

• 訂單表冗余 buyer_nick、seller_nick，避免關聯用戶表。
• 冗余字段同步：應用層雙寫、或觸發器、或 Canal 訂閱 binlog 異步同步。
• 原則：不常修改、頻繁查詢、長度固定的字段適合冗余。

5. 分表分庫（Sharding）

分片鍵選擇：查詢維度一致性（如按 uid 分，所有查詢必帶 uid），避免跨分片查詢。

6. 避坑清單

1. 不要在分片表上建全局自增 ID，用 Snowflake/UUID/分段序列。
2. 分表後 COUNT(*) 需聚合各分片，考慮 Redis 緩存總數。
3. DDL 變更需兼容舊分表，採用「雙寫遷移」或 pt-online-schema-change。
4. 監控分片數據傾斜，定期 Rebalance。