Database 最佳化實踐: VARCHAR(255) 和 256 的 1 之差
為什麼 DB 常見 VARCHAR(255)？
從儲存成本談長度設計的關鍵 在 Navicat 或 ORM 工具中，VARCHAR(255) 是一個頻繁出現的預設設定。這個「比 256 少 1」的數字並非隨意選擇，而是與資料庫底層儲存機制密切相關。要理解其意義，需先釐清 VARCHAR 的實作原理。
一、VARCHAR 的儲存結構：變長字串的代價
column_name VARCHAR(255) -- 變長字串，實際儲存「長度資訊 + 內容」
column_name CHAR(255) -- 定長字串，固定占用 255 字元空間（不足補空白）
VARCHAR 的優勢在於動態分配空間，但需付出額外成本：
儲存「實際內容」的同時，需額外記錄「字串長度」
當長度 ≤ 255 時，長度資訊僅需 1 Byte；超過時則需 2 Bytes
在這一點我們會注意到，VARCHAR 有一個額外的長度資訊，當長度大於 2^8-1 時，額外的長度資訊必須使用 2 Bytes 的空間儲存，會造成額外儲存成本。
二、臨界點 255 的關鍵意義
| 類型 | 最大長度 | 前綴開銷 | 實際開銷 |
|---|---|---|---|
VARCHAR(255) |
255 | 1 Byte | 1 + 內容 |
VARCHAR(256) |
256 | 2 Bytes | 2 + 內容 |
核心問題：從 255 增加到 256 時，僅多儲存 1 個字元，卻導致長度標記的空間開銷翻倍。這是不經濟的。
三、其他長度閾值（如 4095）是否重要？
一般情況下，其他長度邊界最佳化並不重要，並不能帶來更高的效能。
1. 儲存層面
- VARCHAR 最大支援 65,535 Bytes，但長度標記僅使用 1~2 Bytes。
- 超過 255 後（如 256~65535），長度標記固定為 2 Bytes，因此「4095 vs 4096」無差異。
2. InnoDB 頁面限制
- 預設頁大小為 16KB（16384 Bytes），但單行資料理論上限仍為 65,535 Bytes。
- 若使用 utf8mb4 編碼（每字元最多 4 Bytes）：65535 ÷ 4 ≈ 16383 字元，超過此長度時，內容會觸發 溢出儲存（LOB page），影響效能。
四、長文本儲存的最佳實踐
對於文章、日誌等內容，應優先選擇 TEXT 類型而非超長 VARCHAR，原因如下：
1. 行大小限制：
- VARCHAR 雖理論支援 65535 Bytes，但實際上會受到「單一資料列總長度」的限制。
- TEXT 僅在行內儲存 Pointer，內容存放於外部，藉此避免觸發資料列溢位。
2. 效能考量：
- 過長的 VARCHAR 可能強制轉為溢出儲存，失去變長字串的優勢。
五、總結
- 255 是「1 Byte 長度標記」的極限值，平衡儲存效率與實用性。
- 超過 255 時，直接評估是否該用 TEXT 類型，而非盲目增加 VARCHAR 長度。
- 資料庫設計應「夠用即可」，避免因過度預留空間導致隱性成本。