資料型別選擇直接決定磁碟 I/O、記憶體佔用、索引大小與查詢速度。本文系統闡述「越小越好」、「定長優於變長」、「NOT NULL 優於 NULL」、「ENUM 替代字串」四大核心原則,並深入分析 BLOB/TEXT 特性、碎片整理、多欄索引與 PROCEDURE ANALYSE() 智能建議,助你設計高效 Schema。
TINYINT(1B) > SMALLINT(2B) > MEDIUMINT(3B) > INT(4B) > BIGINT(8B)TINYINT UNSIGNED 而非 VARCHAR(20)| 特性 | CHAR / 定長 | VARCHAR / 變長 |
|---|---|---|
| 儲存空間 | 固定,可能浪費 | 實際長度 + 1-2 位元組長度前綴 |
| 更新效能 | 極快(原地修改,無碎片) | 可能導致行遷移、頁分裂、碎片 |
| 索引大小 | 固定 | 可變 |
| 適用場景 | 頻繁 UPDATE、長度固定(MD5、UUID、郵遞區號) | 長度差異大、較少更新 |
建議:高頻寫入表優先用 CHAR、INT、DATE 等定長型別;可接受空間換時間。
WHERE col = NULL 寫錯成 WHERE col IS NULL 的邏輯 BugALTER TABLE、排序按定義順序而非字母序| 問題 | 影響 | 對策 |
|---|---|---|
| 大量 DELETE/UPDATE 產生碎片 | 資料檔留下大洞,後續插入難填補 | 定期 OPTIMIZE TABLE;考慮歸檔策略 | 頻寬浪費、延遲高 | 查詢時 SELECT id, meta FROM t WHERE ... 先過濾,再單獨取 BLOB
| 全文搜尋/前綴匹配受限 | 建立前綴索引 INDEX (blob_col(255)) 或改用全文索引/外部搜尋引擎
|
MD5(blob_col) 儲存雜湊值索引,精確查找用雜湊,範圍查詢無效SELECT * FROM tbl_name PROCEDURE ANALYSE([max_elements, [max_memory]]);
max_elements(預設 256):判斷是否建議 ENUM 的最大不同值數max_memory(預設 8192):分析時每欄最大記憶體SELECT * FROM student PROCEDURE ANALYSE();
SELECT * FROM student PROCEDURE ANALYSE(16, 256); -- 限制 ENUM 建議條件
輸出欄位 Optimal_fieldtype 給出建議型別(如 ENUM('a','b','c')、MEDIUMINT UNSIGNED NOT NULL),據此 ALTER TABLE 調整。
TINYINT/SMALLINT/MEDIUMINT/INT/BIGINT;小數用 DECIMAL(p,s)(精確)或 FLOAT/DOUBLE(近似)CHAR / BINARYENUM / SETVARCHAR / VARBINARYBLOB / TEXT(考慮副表隔離)DATE/TIME/DATETIME(8B)/TIMESTAMP(4B, 時區感知)NOT NULL,預設值用 DEFAULT型別設計是 Schema 設計的地基。每次 CREATE TABLE 前走一遍決策樹,上線後跑 PROCEDURE ANALYSE() 驗證,能省下未來 80% 的調優成本。記住:磁碟便宜,但 I/O 昂貴;記憶體貴,但快取命中率無價。