表的優化與列類型選擇
1. 表的優化
1.1. 定長與變長分離
如 id int, 占4個字節, char(4) 占4個字符長度,也是定長, time
即每一單元值占的字節是固定的.
核心且常用字段,宜建成定長,放在一張表.
而varchar, text,blob,這種變長字段,適合單放一張表, 用主鍵與核心表關聯起來.
1.2. 常用字段和不常用字段要分離.
需要結合網站具體的業務來分析,分析字段的查詢場景,查詢頻度低的字段,單拆出來.
1.3. 合理添加冗余字段.
典型的”空間換時間”
2.列選擇原則
2.1. 字段類型優先級 整型 > date,time > enum,char>varchar > blob
列的特點分析:
整型: 定長,沒有國家/地區之分,沒有字符集的差異
time定長,運算快,節省空間. 考慮時區,寫sql時不方便 where > ‘2005-10-12’;
enum: 能起來約束值的目的, 內部用整型來存儲,但與char聯查時,內部要經歷串與值的轉化
Char 定長, 考慮字符集和(排序)校對集
varchar, 不定長 要考慮字符集的轉換與排序時的校對集,速度慢.
text/Blob 無法使用內存臨時表
2.2. 夠用就行,不要慷慨 (如smallint,varchar(N))
原因: 大的字段浪費內存,影響速度,
以年齡為例 tinyint unsigned not null ,可以存儲
以varchar(10) ,varchar(300)存儲的內容相同, 但在表聯查時,varchar(300)要花更多內存
2.3. 盡量避免用NULL()
原因: NULL不利於索引,要用特殊的字節來標註.
在磁盤上占據的空間其實更大.
2.4. Enum列的說明
1: enum列在內部是用整型來儲存的
2: enum列與enum列相關聯速度最快
3: enum列比(var)char 的弱勢---在碰到與char關聯時,要轉化. 要花時間.
優勢在於,當char非常長時,enum依然是整型固定長度.
當查詢的數據量越大時,enum的優勢越明顯.
enum與
但有時也這樣用-----就是在數據量特別大時,可以節省IO.
原因----無論enum(‘manmaman’,’womanwomanwoman’) 枚舉的字符多長,內部都是用整型表示, 在內存中產生的數據大小不變,而char型,卻在內存中產生的數據越來越多.
總結: enum 和enum類型關聯速度比較快,Enum 類型節省了IO
表的優化與列類型選擇