合理選擇資料型別是資料庫效能、儲存空間與資料正確性的基石。本文系統分析 MySQL 數值、日期時間、字串、枚舉/集合四大類型特性，並給出選型建議與設計策略。
| 型別 | 儲存 | 無符號範圍 | 適用場景 |
|---|---|---|---|
| TINYINT | 1 Byte | 0~255 | 布林旗標、年齡、狀態碼、極小計數 |
| SMALLINT | 2 Bytes | 0~65,535 | 中小計數、年份、郵遞區號 |
| MEDIUMINT | 3 Bytes | 0~16,777,215 | 中等流水號、自增 ID (千萬級以下) |
| INT / INTEGER | 4 Bytes | 0~4,294,967,295 | 通用自增 ID、大計數、外鍵 |
| BIGINT | 8 Bytes | 0~1.84e19 | 極大流水號、分散式 ID、時間戳毫秒 |
策略：選「夠用且最小」的型別。千萬列表用 MEDIUMINT 代替 INT 可省 25% 空間 (3 vs 4 Bytes)。一律加 UNSIGNED 避免負值並擴大正向範圍。
DECIMAL(p,s) / NUMERIC(p,s)：以字串形式儲存每位數字，不會浮點誤差。| 型別 | 精度 | 範圍 | 儲存 |
|---|---|---|---|
| FLOAT | ~7 位有效數字 | ±1.17e-38 ~ ±3.4e38 | 4 Bytes |
| DOUBLE | ~15 位有效數字 | ±2.22e-308 ~ ±1.8e308 | 8 Bytes |
策略：僅用於物理量測、科學計算、經緯度等可容許微小誤差的場景。嚴禁用於金額。
| 型別 | 儲存 | 範圍 | 適用 |
|---|---|---|---|
| DATE | 3 Bytes | 1000-01-01 ~ 9999-12-31 | 生日、入職日、訂單日期 (無需時間) |
| TIME | 3 Bytes | -838:59:59 ~ 838:59:59 | 每日固定時段、耗時長度 |
| DATETIME | 8 Bytes | 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 | 通用時間戳、建立/更新時間 |
| TIMESTAMP | 4 Bytes | 1970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07 UTC | 自動更新欄位 (DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP)、跨時區應用 |
| YEAR | 1 Byte | 1901 ~ 2155 | 年份選單 |
策略：TIMESTAMP 會自動轉換時區 (儲存 UTC，讀取依 time_zone)，DATETIME 不轉換。跨時區系統優先用 TIMESTAMP 或統一應用層處理 UTC。
| 型別 | 長度特性 | 儲存開銷 | 適用 |
|---|---|---|---|
| CHAR(n) | 固定長度 | n Bytes | 定長代碼 (ISO 國別碼、身分證字號、MD5 雜湊) |
| VARCHAR(n) | 可變長度 | 實際長度 + 1~2 Bytes | 不定長文字 (姓名、標題、描述、Email) |
| TINYTEXT | ≤255 Bytes | L + 1 | 極短文本 |
| TEXT | ≤64 KB | L + 2 | 文章內容、日誌、JSON 文檔 |
| MEDIUMTEXT | ≤16 MB | L + 3 | 長文本 |
| LONGTEXT | ≤4 GB | L + 4 | 超大文本 |
關鍵判斷：若欄位值長度幾乎固定 (如 MD5 固定 32 字元、手機號 11 位)，用 CHAR 省去長度前綴；否則用 VARCHAR。VARCHAR(255) 在 utf8mb4 下單列上限約 255×4+2=1022 Bytes，接近 InnoDB 行大小限制，大文本請改用 TEXT 家族。
ENUM('M','F')、狀態 ENUM('active','inactive','pending')。比 TINYINT 更具可讀性，效能相同。注意：ENUM/SET 元素修改需 ALTER TABLE (鎖表)，頻繁變動的選項建議改用查閱表 (Lookup Table) + 外鍵。
TINYINT > SMALLINT > MEDIUMINT > INT > BIGINT，CHAR > VARCHAR > TEXT。DECIMAL(10,2) 或 DECIMAL(12,4) 視精度需求。DATETIME (應用層寫入 UTC) 或 TIMESTAMP (自動 UTC 轉換)，二選一全專案一致。created_at)，避開保留字，意圖清晰。資料型別選型直接影響儲存成本、索引效率、查詢速度與資料正確性。掌握各型別的儲存機制、範圍與適用邊界，並在設計評審階段嚴格把關，是高效能 MySQL 架構的基礎功夫。
