合理選擇數據類型是表設計的基石，直接影響存儲空間、索引效率、查詢性能與數據正確性。本文按類別系統梳理 MySQL 所有數據類型的特點、適用場景與選型建議。
| 類型 | 最大長度 | 存儲特點 | 適用場景 |
|---|---|---|---|
CHAR(n) | 255 字節 | 定長，不足右補空格，讀取去除尾部空格 | 固定長度：MD5、UUID、郵編、手機號(定長) |
VARCHAR(n) | 65,535 字節 (共享 64KB) | 變長，1-2 字節存長度，按實際內存存儲 | 不定長文本：姓名、地址、郵箱 |
TINYTEXT | 255 字節 | 不需指定長度，離頁存儲 | 極短文本 |
TEXT | 64 KB | 離頁存儲 | 文章、描述 |
MEDIUMTEXT | 16 MB | 離頁存儲 | 長文本 |
LONGTEXT | 4 GB | 離頁存儲 | 超大文本 |
⚠️ CHAR vs VARCHAR：頻繁 UPDATE 定長列用 CHAR 避免碎片；可變長度優先 VARCHAR。
VARCHAR(255)在 utf8mb4 下佔 767 字節，超過則需遷移到 TEXT 或調整索引前綴長度。
| 類型 | 字節 | 有符號範圍 | 無符號範圍 |
|---|---|---|---|
TINYINT | 1 | -128 ~ 127 | 0 ~ 255 |
SMALLINT | 2 | -32,768 ~ 32,767 | 0 ~ 65,535 |
MEDIUMINT | 3 | -8,388,608 ~ 8,388,607 | 0 ~ 16,777,215 |
INT | 4 | -2,147,483,648 ~ 2,147,483,647 | 0 ~ 4,294,967,295 |
BIGINT | 8 | -9.22e18 ~ 9.22e18 | 0 ~ 1.84e19 |
💡 手機號存儲：
BIGINT(8B) 優於CHAR(11)(utf8mb4 33B / latin1 11B)，可用CAST轉換。
| 類型 | 字節 | 精度 | 適用場景 |
|---|---|---|---|
DECIMAL(M,D) | M+2 (約) | 精確 | 金額、價格、利率 (字符串存儲，無精度損失) |
FLOAT | 4 | ~7 位有效數字 | 科學計算、坐標、近似值 |
DOUBLE | 8 | ~15 位有效數字 | 高精度近似計算 |
💰 金融金額必用 DECIMAL，
FLOAT/DOUBLE存在二進制精度損失，如0.1 + 0.2 != 0.3。
| 類型 | 字節 | 範圍 | 特點 |
|---|---|---|---|
DATE | 4 | 1000-01-01 ~ 9999-12-31 | 純日期 |
TIME | 3 | -838:59:59 ~ 838:59:59 | 純時間/時長 |
DATETIME | 8 | 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 | 無時區，靜態時間點 |
TIMESTAMP | 4 | 1970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07 UTC | 帶時區自動轉換，受時區影響 |
YEAR | 1 | 1901 ~ 2155 | 僅年份 |
🕐 選型建議：用戶操作時間用
DATETIME保持原意；系統日志、創建/更新時間用TIMESTAMP自動維護時區；5.6+ 支持微秒精度DATETIME(6)。
| 類型 | 最大長度 |
|---|---|
TINYBLOB | 255 B |
BLOB | 64 KB |
MEDIUMBLOB | 16 MB |
LONGBLOB | 4 GB |
📁 最佳實踐：文件/圖片存對象存儲 (S3/OSS)，數據庫只存 URL。BLOB 導致備份巨大、複製緩慢、緩存污染。
-- 存儲：INET_ATON('192.168.1.1') → 3232235777 (INT UNSIGNED)
-- 讀取：INET_NTOA(3232235777) → '192.168.1.1'
CREATE TABLE ip_log (ip INT UNSIGNED NOT NULL);
INSERT INTO ip_log VALUES (INET_ATON('192.168.1.1'));只需 4 字節，支持范圍查詢 WHERE ip BETWEEN INET_ATON('192.168.1.0') AND INET_ATON('192.168.1.255')。
