如id int ,佔四個位元組；char(4)，佔四個字元長度，也是定長；time即每乙個單元值佔的位元組是固定的；核心且常用字段，宜建成定長，放在一張表，而varchar、text、bolb這種邊長的字段，適合單方一張表，用主鍵與核心表關聯起來。
需要結合**具體業務來分析，分析欄位的查詢場景，查詢頻度低的字段，單拆出來
在一對多需要關聯統計的字段上，新增冗餘字段，減少資料庫關聯查詢
整型》date,time>enum>char>varvhar>blob,text
列特點分析：
整型：定長，沒有國家/地區之分，沒有字符集的差異。
比如：tinyint 1,2,3,4,<-->char(1) a,b,c,d
從空間上都是占用乙個位元組，但是order by 排序，前者快，後者慢
原因：後者需要考慮到字元集合校對集（就是排序規則）
time：定長，運算快，節省時間，考慮時區，寫sql不方便 where >『2015-12-04』;
enum：能起到約束值的目的，內部用整型來儲存，但與char聯查時，內部要經歷串與值的轉換。
char：定長，需要考慮字符集和校對集（排序）。
varchar：不定長，要考慮字符集轉換與排序時的校對集，速度慢。
text/bolb：無法使用記憶體臨時表（排序操作只能在磁碟上進行）
附：關於date/time選擇，大師的明確意見，直接選int unsgined not null,存時間戳
性別：以utf-8為例
cahr(1),3個字長位元組
enum('男','女')；//內部轉換成數字來儲存，多了乙個轉換過程。
tinyint();// 0 1 2//定長乙個位元組
原因：大的字段浪費記憶體，影響速度。以年齡為例 tinyint unsiged not null，可以儲存255歲，足夠，用int浪費了三個位元組
以varchar(10)，varchar(300)儲存的內容相同，但是在表聯查時varchar(300)yaohua gengduo de neicun
原因：null不利於索引，需要用特殊的位元組來標註在磁碟上佔據的空間其實更大（mysql5.7已經對null做了改進，但查詢仍是不便）
另外：null也不便於查詢
where 列明=null;
where 列明!=null; 都查不到值
where 列明 is null 或is not null 才可以查詢
表的優化與列型別選擇
如 id int,佔 4個位元組 char 4 佔4 個字元長度 也是定長 time 即每一單元值佔的位元組是固定的.核心且常用字段,宜建成定長 放在一張表 而varchar,text,blob,這種變長字段 適合單放一張表 用主鍵與核心表關聯起來 需要結合 具體的業務來分析,分析欄位的查詢場景 查...
mysql優化 表的優化與列型別的選擇
定長與變長分離 常用字段和不常用字段分離 合理增加冗餘字段 字段型別優先順序 整型 date,time enum,char varchar blob 列的特點分析 整型 定長,沒有國家 地區之分,沒有字符集的差異 time 定長,運算快,節省空間.考慮時區 enum 能起來約束值的目的,內部用整型來...
MySQL優化筆記02 列型別的選擇
字段型別優先順序排序 整型 date,time enum,char varchar blob 列的特點分析 整型 定長,沒有國家 地區之分,沒有字符集的差異 time 定長,運算快,節省空間.考慮時區,寫sql時不方便 where 2005 10 12 enum 能起來約束值的目的,內部用整型來儲存...