MySQL 表結構優化 5 大建議：數據類型選擇、字符集、拆分、冗餘與 NOT NULL

傳統三範式在大數據量、高併發下往往成為性能瓶頸。本文從「減少 IO、提高緩存命中率」出發，給出 5 條反直覺但實戰有效的優化原則。

一、數據類型：越小越好，越簡單越好

1. 整數：區分 TINYINT/SMALLINT/MEDIUMINT/INT/BIGINT，非負加 UNSIGNED。1 億用戶用 INT UNSIGNED 即夠，別濫用 BIGINT。
2. 小數：禁用 FLOAT/DOUBLE（精度陷阱），慎用 DECIMAL（存儲佔用大、計算慢）。推薦：乘固定倍數轉整數存儲，如金額存「分」，汇率存「萬分位」。
3. 字符：定長用 CHAR，變長用 VARCHAR 且長度剛好夠用。拒絕 TEXT/BLOB，除非必須；它們強制 off-page 存儲，破壞緩存局部性。
4. 時間：優先 TIMESTAMP（4 字節，1970~2038），次選 DATETIME（8 字節），再選 DATE（3 字節，僅需日期）。勿用 INT 存 Unix 時間戳，不可讀、維護成本高、無增益。
5. 枚舉/集合：狀態碼用 ENUM（1~2 字節），多屬性用 SET（位掩碼），極省空間且索引快。
6. LOB：堅決不存。圖片/文件丟對象存儲（S3/MinIO/OSS），庫裡只存 URL/路徑。

二、字符集：按需最小化

• 純拉丁字符用 latin1，省 50%+ 空間。
• 單語言業務無需 utf8mb4，用 gbk 或 latin1 更緊湊。
• MySQL 支援列級字符集，大表核心列用緊湊編碼，非核心列用通用編碼，混合最優。

三、適當拆分（垂直拆表）

大字段（TEXT、長 VARCHAR、JSON）低頻訪問 → 獨立表，主表只保高頻列。效果：

• 單頁容納更多行 → 物理 IO ↓、邏輯讀 ↓。
• 緩存命中率 ↑，熱數據更集中。

四、適度冗餘（反範式）

場景：高頻 JOIN 大表只為取一個小字段（如用戶名、商品標題）。

• 冗餘該字段到主表，查詢避開 JOIN。
• 代價：寫入時需同步更新冗餘列（應用層或觸發器保證一致性）。
• 收益：大表 JOIN 消失，IO 驟降，延遲從毫秒級降至微秒級。

五、盡量 NOT NULL

• NULL 進組合索引會嚴重降低索引效率（需額外標記位、特殊比較邏輯）。
• NULL 佔額外存儲（位圖），並不省空間。
• 預設值用 ''、0、'1970-01-01' 等業務無效值，統一語義，簡化查詢條件。

優化本質是空間換時間、冗餘換速度。在「數據量大、讀多寫少、訪問模式固定」的核心業務表上激進應用上述原則，收益顯著；邊緣表保持範式，降低維護成本。