數據類型是 Schema 設計的基石，直接影響存儲空間、查詢性能、索引效率、數據質量。本文系統梳理 MySQL 三大類常用類型（數值、字符串、日期時間）的子類型特點、適用場景、精度陷阱，並給出選型五大黃金標準，助你設計高效、可維護的表結構。

一、數值類型

1. 整數類型

類型	存儲字節	有符號範圍	無符號範圍	典型場景
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 / INTEGER	4	-2,147,483,648 ~ 2,147,483,647	0 ~ 4,294,967,295	通用 ID、計數器、外鍵
BIGINT	8	-9e18 ~ 9e18	0 ~ 1.8e19	巨大 ID、高精度時間戳(毫秒/微秒)

INT(5) 中的 5 僅為顯示寬度（配合 ZEROFILL），不限制存儲範圍。

2. 浮點/定點類型

類型	精度	存儲	適用場景
FLOAT(M,D)	單精度 ~7 位有效數字	4 字節	科學計算、非精確金額
DOUBLE(M,D)	雙精度 ~15 位有效數字	8 字節	高精度科學計算
DECIMAL(M,D) / NUMERIC	精確定點數，M 總位數，D 小數位	變長 (M+2 字節)	金融、價格、庫存、任何不可有誤差場景

示例：

CREATE TABLE t (price DECIMAL(10,2));
INSERT INTO t VALUES (45.678);  -- 存儲 45.68（四捨五入）

二、字符串類型

類型	最大長度	存儲特點	適用場景
CHAR(n)	255 字符	定長，右側填充空格	固定長度代碼：MD5、UUID、國標代碼、性別
VARCHAR(n)	65,535 字符 (行上限)	變長，1-2 字節存長度 + 實際內容	不定長文本：姓名、標題、URL、JSON 片段
TINYTEXT/TEXT/MEDIUMTEXT/LONGTEXT	255 / 64K / 16M / 4G	對象存儲，不在行內，需額外 IO	長文本：文章、日誌、序列化對象
BLOB 系列	同 TEXT	二進制，區分大小寫	圖片、文件、加密數據

關鍵差異：

• CHAR 按定長分配，VARCHAR 按實際長度分配，不確定長度首選 VARCHAR
• TEXT/BLOB 不在行內存儲，查詢需額外 IO，避免 SELECT * 掃描大字段
• BLOB 比較/排序區分大小寫，TEXT 不區分
• UTF8 下 CHAR/VARCHAR 長度按字符計算，存儲按字節（1-3 字節/字符）

三、日期時間類型

類型	範圍	存儲	格式示例	典型用途
DATE	1000-01-01 ~ 9999-12-31	3 字節	'2024-01-15'	生日、入職日期
TIME	-838:59:59 ~ 838:59:59	3 字節	'12:30:45'	每日營業時間、耗時
YEAR	1901 ~ 2155	1 字節	2024	年份歸檔
DATETIME	1000-01-01 00:00:00 ~ 9999-12-31 23:59:59	8 字節	'2024-01-15 12:30:45'	業務時間、創建/更新時間（不隨時區變化）
TIMESTAMP	1970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07 UTC	4 字節	自動轉換為會話時區	日誌時間戳、跨時區應用、自動更新列

輸入格式：字符串用分隔符 ('-' ':') 或無分隔符整數 (20240115123045)。

自動屬性：

• 表中第一個 TIMESTAMP 列，若插入 NULL 或省略，自動填充當前時間戳
• DATETIME 配合 NOW() / CURRENT_TIMESTAMP 手動填充
• YEAR 兩位數自動轉換：00-69 → 2000-2069，70-99 → 1970-1999

四、數據類型選型五大黃金標準

1. 允許值範圍：業務數據可能取值範圍決定類型上下界（如狀態碼用 TINYINT UNSIGNED）
2. 存儲效率：够用就好，越小越好。INT 4 字節 vs BIGINT 8 字節，億級表差距 400MB+
3. 格式與顯示要求：IP 地址用 INT UNSIGNED 存儲（INET_ATON/INET_NTOA），枚舉用 ENUM 或 TINYINT + 字典表
4. 數據處理需求：頻繁計算用整數/定點數；全文搜索用 TEXT + 全文索引；JSON 用 JSON 類型 (5.7+)
5. 排序、索引、比較兼容性：
   - 同類型比較才能用上索引（隱式轉換導致索引失效）
   - CHAR/VARCHAR 排序受 COLLATION 影響
   - 外鍵雙方類型、長度、字符集、校驗規則必須完全一致

五、避坑速查表

• ❌ 金額用 FLOAT/DOUBLE → ✅ DECIMAL(10,2)
• ❌ 手機號用 INT → ✅ BIGINT 或 CHAR(11)（保留前導 0）
• ❌ 通用 ID 用 BIGINT 卻存雪花算法 64 位 → ✅ 確認範圍足夠
• ❌ VARCHAR(255) 當萬金油 → ✅ 實際業務長度 + 20% 冗余
• ❌ 時區敏感業務用 DATETIME → ✅ TIMESTAMP 或應用層統一 UTC
• ❌ 表結構頻繁變更 → ✅ 核心表定型後凍結 Schema，擴展屬性走 JSON/EAV