MySQL 數據瘦身實戰：五大策略讓資料庫跑得更快

資料庫優化的核心原則之一是「數據越小，速度越快」。縮減表體積不僅能提升磁碟 I/O 效率，還能降低記憶體佔用、縮小索引體積、加快備份恢復。本文總結五大實戰瘦身策略，助你構建輕量高效的 MySQL 實例。

策略一：拒絕 NULL，預設非空

許多 DBA 錯誤認為 NULL 不佔空間，實則每個允許 NULL 的列會額外消耗 1 位標記位。建議：所有列預設 NOT NULL，必要時用預設值（如薪資年限預設 0）替代空值。 僅在業務真正需要「未知」語義時才允許 NULL。這不僅節省存儲，還能加速查詢判斷。

策略二：選用最小足夠的數據類型

• 整數優先級： TINYINT > SMALLINT > MEDIUMINT > INT > BIGINT。同為整數，MEDIUMINT 比 INT 節省 25% 空間，能滿足業務範圍時優先選用。
• 字串定長： 若員工編碼固定 5 碼，定義 CHAR(5) 而非 VARCHAR(20)，既省空間又隱含長度校驗。
• 日期時間： TIMESTAMP (4 字節) 比 DATETIME (8 字節) 更緊湊，適合 1970-2038 年範圍內的場景。

策略三：索引瘦身與精準建立

索引體積與表體積同步增長，主鍵越短，二級索引越小（InnoDB 二級索引葉子節點存主鍵值）。實踐原則：

• 主鍵採用自增整數或短業務碼，避免 UUID、長字串。
• 利用前綴索引：列值前 N 字元區分度已足夠時，只索引前綴（INDEX idx_name (col(10))），大幅縮小索引體積並提升緩存命中率。
• 拒絕過度索引：唯有「查詢收益 > 維護成本」時才建索引；聯合索引遵循最左前綴，避免單列索引堆疊。

策略四：該定長時定長，別盲目追求變長

MyISAM 表若無任何變長列（VARCHAR、TEXT、BLOB），全表定長行格式雖稍浪費空間，但讀取速度極快（定位行只需 行號 × 行長）。權衡原則：讀多寫少、行長固定的表宜定長；頻繁更新、長度差異大的表用變長。 不要為了「省空間」犧牲核心查詢路徑的效能。

策略五：大表拆分，化整為零

單表超過 2000 萬行或 20 GB 時，維護成本指數級上升。拆分策略：

• 水平分表： 按時間（月/年）、租戶、地域等業務維度拆分為多個同結構表，配合合併視圖或中間件路由。
• 垂直拆分： 將大字段（TEXT、BLOB）或低頻列移至擴展表，主表只保高頻小列。
• 歸檔歷史： 熱數據留主表，冷數據定期歸檔至存儲成本更低的引擎或離線倉庫。

拆分規則設計直接決定成敗，需結合查詢模式、事務邊界、運維能力綜合評估。

總結

數據瘦身不是單純「刪減」，而是在正確的地方精簡，在關鍵的地方豐滿。從列定義、類型選擇、索引設計、行格式到分表歸檔，每一步都要以「核心查詢路徑最優」為準繩。定期用 ANALYZE TABLE、OPTIMIZE TABLE 檢視碎片與統計信息，持續迭代，才能讓 MySQL 長期保持輕盈高效。