在讀多寫少、一致性要求可延遲的場景，將關聯表的高頻欄位冗餘到主表，以空間換時間，消除 JOIN 開銷。
summary 表：僅存核心欄位，支援高頻列表查詢
detail 表：存大文本（TEXT/BLOB）、低頻屬性，按需 JOIN定時任務/觸發器/ Canal 同步 Binlog 彙總統計數據，查詢直接讀統計表，避免大表 COUNT/SUM 掃描。
| 場景 | 推薦型別 | 理由 |
|---|---|---|
| 時間戳（1970 後） | TIMESTAMP (4B) | 比 DATETIME(8B) 省一半空間 |
| 1970 前時間 | DATETIME / DATE | TIMESTAMP 不支援 |
| 固定長度字串 | CHAR(M) | 定長存取快，不足補空格 |
| 變長字串 | VARCHAR(M) | 實際長度+1-2B 長度前綴 |
| 大文本 | TEXT 系列 | 溢位頁存儲，不在行內 |
| 枚舉值集合 | ENUM | 內部 TINYINT，極省空間 |
| IP 地址 | INT UNSIGNED | 4B，範圍查詢極快 |
| 級別 | 髒讀 | 不可重複讀 | 幻讀 | 適用場景 |
|---|---|---|---|---|
| READ UNCOMMITTED | ✅ | ✅ | ✅ | 極低一致性需求，如日誌寫入 |
| READ COMMITTED | ❌ | ✅ | ✅ | 大多數 OLTP，需鎖定讀一致性 |
| REPEATABLE READ (InnoDB 預設) | ❌ | ❌ | ✅ | 金融/訂單核心業務，MVCC 實現 |
| SERIALIZABLE | ❌ | ❌ | ❌ | 極高一致性，效能最差，慎用 |
InnoDB 關鍵機制： MVCC（多版本並發控制）配合 Next-Key Lock 在 REPEATABLE READ 下實現「無幻讀」（大多數情況），但純
INSERT仍可能出現幻讀，需評估業務容忍度。
| 優點 | 缺點 |
|---|---|
| 拆分規則清晰、模組解耦、維護容易 | 跨庫 JOIN/事務複雜、熱點表仍受限、擴展性有上限 |
| 優點 | 缺點 |
|---|---|
| 單表體積可控、寫入擴展性強、事務簡單 | 路由規則複雜、跨分片查詢難、運維成本高 |
WHERE id IN (...) 查被驅動表。
架構鐵律： 過早優化是萬惡之源。先建立監控基線，量化瓶頸，再以最小代價解決最大痛點。每一層架構引入都要經過「成本-收益-風險」三維評估。
