1. MySQL數(shù)據(jù)類型概述作為關(guān)系型數(shù)據(jù)庫的基石MySQL的數(shù)據(jù)類型系統(tǒng)直接影響著數(shù)據(jù)存儲(chǔ)效率、查詢性能和系統(tǒng)穩(wěn)定性。我在實(shí)際項(xiàng)目中見過太多因?yàn)閿?shù)據(jù)類型選擇不當(dāng)導(dǎo)致的性能問題一個(gè)本該用TINYINT的字段被定義成INT導(dǎo)致百萬級(jí)數(shù)據(jù)表體積膨脹30%用VARCHAR(255)存儲(chǔ)固定長度的MD5值白白浪費(fèi)了20%存儲(chǔ)空間...MySQL的數(shù)據(jù)類型主要分為三大類數(shù)值類型包括整數(shù)和浮點(diǎn)數(shù)字符串類型包含文本和二進(jìn)制數(shù)據(jù)日期時(shí)間類型處理各種時(shí)間格式每種類型都有其特定的存儲(chǔ)需求和適用場(chǎng)景。比如同樣是存儲(chǔ)年齡TINYINT UNSIGNED就比INT更適合因?yàn)槿祟惸挲g不可能超過255歲更不可能是負(fù)數(shù)。關(guān)鍵原則選擇能滿足需求的最小數(shù)據(jù)類型。這不僅節(jié)省存儲(chǔ)空間更能提升索引效率。2. 數(shù)值類型深度解析2.1 整數(shù)類型實(shí)戰(zhàn)選擇MySQL提供5種整數(shù)類型它們的區(qū)別主要體現(xiàn)在存儲(chǔ)空間和取值范圍上類型字節(jié)有符號(hào)范圍無符號(hào)范圍TINYINT1-128 ~ 1270 ~ 255SMALLINT2-32768 ~ 327670 ~ 65535MEDIUMINT3-8388608 ~ 83886070 ~ 16777215INT/INTEGER4-2147483648 ~ 21474836470 ~ 4294967295BIGINT8-2^63 ~ 2^63-10 ~ 2^64-1實(shí)際項(xiàng)目中的經(jīng)驗(yàn)法則狀態(tài)字段用TINYINT比如訂單狀態(tài)(0未支付,1已支付)外鍵ID用INT足夠除非是超大型系統(tǒng)自增主鍵建議用UNSIGNED避免負(fù)數(shù)浪費(fèi)一半空間-- 典型錯(cuò)誤示例用BIGINT存儲(chǔ)用戶年齡 CREATE TABLE user ( age BIGINT -- 浪費(fèi)7個(gè)字節(jié) ); -- 正確做法 CREATE TABLE user ( age TINYINT UNSIGNED -- 只需1字節(jié) );2.2 浮點(diǎn)數(shù)精準(zhǔn)陷阱FLOAT和DOUBLE作為近似值類型在進(jìn)行等值比較時(shí)會(huì)出現(xiàn)精度問題-- 會(huì)產(chǎn)生意想不到的結(jié)果 SELECT 0.1 0.2 0.3; -- 返回0(false)金融類數(shù)據(jù)必須使用DECIMALCREATE TABLE account ( balance DECIMAL(10,2) -- 10位精度2位小數(shù) );血淚教訓(xùn)曾經(jīng)有個(gè)電商項(xiàng)目因?yàn)橛肍LOAT存儲(chǔ)金額導(dǎo)致對(duì)賬時(shí)出現(xiàn)0.01元的差額排查了整整兩天3. 字符串類型實(shí)戰(zhàn)指南3.1 CHAR與VARCHAR的抉擇特性CHARVARCHAR存儲(chǔ)方式固定長度可變長度空格處理自動(dòng)補(bǔ)足空格保留原樣適用場(chǎng)景定長數(shù)據(jù)(如MD5)變長數(shù)據(jù)(如地址)實(shí)測(cè)對(duì)比存儲(chǔ)100萬個(gè)MD5值(固定32字符)CHAR(32)占用32MBVARCHAR(32)占用約38MB(有額外長度標(biāo)識(shí))3.2 文本類型使用場(chǎng)景TEXT系列存儲(chǔ)大段文本分TINYTEXT(255B)、TEXT(64KB)、MEDIUMTEXT(16MB)、LONGTEXT(4GB)BLOB系列存儲(chǔ)二進(jìn)制數(shù)據(jù)分類與TEXT對(duì)應(yīng)重要限制TEXT/BLOB列不能有默認(rèn)值也不能用作索引的全部內(nèi)容4. 時(shí)間類型的精妙運(yùn)用4.1 各時(shí)間類型對(duì)比類型格式范圍存儲(chǔ)需求DATEYYYY-MM-DD1000-01-01~9999-12-313字節(jié)TIMEHH:MM:SS-838:59:59~838:59:593字節(jié)DATETIMEYYYY-MM-DD HH:MM:SS1000-01-01 00:00:00~9999-12-31 23:59:598字節(jié)TIMESTAMPYYYY-MM-DD HH:MM:SS1970-01-01 00:00:01~2038-01-19 03:14:074字節(jié)4.2 時(shí)區(qū)陷阱與解決方案TIMESTAMP會(huì)轉(zhuǎn)換為UTC存儲(chǔ)檢索時(shí)再轉(zhuǎn)回當(dāng)前時(shí)區(qū)而DATETIME不會(huì)-- 假設(shè)服務(wù)器時(shí)區(qū)為UTC8 CREATE TABLE events ( dt DATETIME, ts TIMESTAMP ); INSERT INTO events VALUES (2023-01-01 08:00:00, 2023-01-01 08:00:00); -- 修改時(shí)區(qū)后查詢 SET time_zone 00:00; SELECT * FROM events; -- 結(jié)果dt顯示08:00:00ts顯示00:00:00跨時(shí)區(qū)系統(tǒng)建議統(tǒng)一使用DATETIME存儲(chǔ)前端負(fù)責(zé)時(shí)區(qū)轉(zhuǎn)換。5. 類型選擇性能優(yōu)化實(shí)戰(zhàn)5.1 索引效率對(duì)比測(cè)試在100萬數(shù)據(jù)的用戶表上測(cè)試-- 方案1手機(jī)號(hào)存為VARCHAR(20) ALTER TABLE users ADD INDEX idx_phone(phone); -- 查詢耗時(shí)約120ms -- 方案2手機(jī)號(hào)存為CHAR(11) ALTER TABLE users ADD INDEX idx_phone(phone); -- 查詢耗時(shí)約85ms定長字段的索引效率通常更高但需權(quán)衡存儲(chǔ)空間。5.2 隱式類型轉(zhuǎn)換陷阱-- 假設(shè)mobile字段是VARCHAR EXPLAIN SELECT * FROM users WHERE mobile 13800138000; -- 會(huì)發(fā)現(xiàn)使用了全表掃描而不是索引必須保持查詢條件與字段類型一致這是最常見的性能殺手之一。6. 特殊類型與應(yīng)用場(chǎng)景6.1 ENUM與SET類型ENUM適合固定選項(xiàng)-- 節(jié)省存儲(chǔ)空間 CREATE TABLE shirts ( size ENUM(x-small, small, medium, large, x-large) );SET適合多選場(chǎng)景CREATE TABLE permissions ( flags SET(read, write, delete, admin) );6.2 JSON類型實(shí)戰(zhàn)MySQL 5.7支持原生JSON類型CREATE TABLE products ( attributes JSON, INDEX idx_attrs ((CAST(attributes-$.color AS CHAR(20)))) ); -- 查詢紅色商品 SELECT * FROM products WHERE JSON_EXTRACT(attributes, $.color) red;JSON類型的索引需要通過生成列實(shí)現(xiàn)這是NoSQL特性在關(guān)系型數(shù)據(jù)庫中的巧妙融合。