MySQL 表結構優化實戰：打破三範式迷思，空間換時間的藝術

前言：三範式不是銀彈

許多開發者視資料庫三範式為聖經，實則在大數據量、高併發場景下，嚴格遵循三範式反而會拖垮效能。MySQL 採行式儲存，減少單行大小 → 單頁容納更多行 → 減少 IO → 提升快取命中率。本文分享實戰驗證的表結構優化技巧。

一、資料型別選擇：精準定型，拒絕浪費

數值型別

• 拒絕 DOUBLE：精度問題且佔 8 bytes，定點數乘固定倍數轉 BIGINT 儲存。
• 慎用 DECIMAL：同理，轉整數儲存節省空間且無維護成本。
• 整數分級：TINYINT(1B) SMALLINT(2B) MEDIUMINT(3B) INT(4B) BIGINT(8B)，按業務上限選最小型別。
• 非負數加 UNSIGNED：正數範圍翻倍，零成本。

字串型別

• 拒絕 TEXT/BLOB：處理效率遠低於 CHAR/VARCHAR，且易導致行溢位。
• 定長用 CHAR，變長用 VARCHAR 且設合理上限（如手機號 VARCHAR(11) 而非 255）。

時間型別

• 優先 TIMESTAMP(4B)：比 DATETIME(8B) 省一半空間。
• 精確到日用 DATE(3B)：更小。
• 拒絕 INT 存 Unix Timestamp：可讀性差、維護痛苦、無效能優勢。

ENUM & SET：狀態欄位神器

• ENUM：單選狀態，1-2 bytes，新增值只需 ALTER TABLE ... ADD VALUE 不重建表。
• SET：多選屬性，位元運算極快，同樣節省空間。

LOB 型別：堅決不存資料庫

圖片、文件、大文本交給對象儲存（S3、MinIO、FastDFS），資料庫只存路徑。讓專業工具做專業的事。

二、字元集策略：按需分配，避免 UTF-8 濫用

• 純拉丁字元（英文、數字）用 latin1，節省 50%+ 空間。
• 確定無多語言需求，不必全庫 UTF-8。
• MySQL 支援欄位級字元集，大表核心欄位用緊湊編碼，異語欄位單獨指定 UTF-8。

三、垂直拆分：大欄位隔離，熱資料瘦身

含 TEXT/大 VARCHAR 欄位且高頻查詢不需該欄位時，拆至獨立表（一對一關聯）。

• 主表行長大幅縮減 → 單頁行數激增 → IO 驟降、快取命中率飆升。
• 典型案例：商品表拆出 description、用戶表拆出 profile_json。

四、適度冗余：反範式的藝術

場景：頻繁 JOIN 兩張大表只為取一個小欄位（如訂單列表顯示用戶姓名）。

• 冗余 user_name 至訂單表，以空間換時間，消除 JOIN IO。
• 鐵律：冗余欄位必須有機制保證一致性（觸發器、應用層雙寫、訊息佇列同步）。

五、堅持 NOT NULL：NULL 是優化殺手

• 組合索引包含 NULL 欄位會嚴重降低索引效率。
• NULL 在索引中需額外位元組標記，反而佔空間。
• IS NULL/IS NOT NULL 優化困難，DEFAULT '' 或 0 更友善。

總結

表結構優化核心是「縮小行長 → 減少 IO → 提升快取」，偶需「適度冗余換 JOIN 效能」。沒有銀彈，只有基於業務場景的取捨。